Since everyone should write more tests we put your test results into VSCode.
Currently supported test frameworks:
munit
utest
haxe.unit
buddy (added in 1.1.0)
hexUnit (added in 1.2.0)
tink_unittest (added in 1.2.0)
Works for nodejs and sys targets.
Just install haxe-test-explorer from VSCode Marketplace (Haxe Test Explorer) and you are all set. No need to modify your code (see usage section on haxe-test-adapter).
You can now press Run all tests from test explorer view inside VSCode and you will see results showing up.
From there you can run individual tests, you can even run them from within your test classes (*).
For a more permanent integration of test results you can add -lib test-adapter to your buildTest.hxml (or whatever you use to run tests).
There is also limited debugging support.
We have demo projects for all supported testing frameworks on our github page.
(*) line number detection of test functions only works with Haxe 4, in Haxe 3 you can run individual tests and see error line decoration, but there is no gutter icons, codelens or jumping from test explorer into test function
I must be missing something though - can’t get it to work. Being on Win, Haxe 4 RC 1, VSCode 1.31.1
VSCode Haxe Extension 2.6.0 and Test Explorer UI 2.4.0 installed.
So are haxelibs test-adapter-1,0,0 and hx3compat-1,0,3
I’ve download the latest test haxe-test-adapter samples (1.0.0) , navigated into the samples/haxeunits folder and started VSCode from there.
Compiling the test.hxml the normal way gives the expected output.
But when running the “Test Explorer: Run all tests” command, nothing happens. (No matter if i use the Command palette or the button in the Test Explorer left panel.)
Adding the “haxeTestExplorer.testCommand” settings described in the readme to the [Haxe] section of settings.json doesn’t change anything.
Tested quick on another win machine, and it doesn’t seem to work there either.
Do you see a folder called .unittest and does it contain positions.json and results.json?
The extension basically runs haxe test.hxml -lib test-adapter to get test results, so does that generate .unittest and contents? (it is safe to delete .unittests)
Does any error mesage show up in VSCode’s developer console?
You don’t need to make any changes to settings for the samples, they’re set up so they work with the defaults (having a hxml file named test.hxml and a launch config named Debug).
We have added support for buddy and released version 1.1.0!
A buddy sample project was added to the list of samples.
There are now four small demo projects using different testing frameworks in our samples folder - go check them out on github!
It’s only a minor update, but we released version 1.2.1 earlier today.
We improved the way test explorer detects your test classes especially for utest, buddy and haxe.unit test frameworks.
For munit, tink_unittest and hexunit your test classes should have Test somewhere in their names. If that is not the case you can use a new define called -D test-adapter-filter=<filter>, where you can set a regex that matches your test classes (just add it to your haxeTestExplorer.testCommand setting in VSCode).
There were also some internal changes on how we generate and use suite and test ids.
Not really an update to Haxe test explorer, but there is a new extension written for Test Explorer UI that will display a summary of test results in your status bar. You can find it here: Test Explorer Status Bar
It includes a bugfix for utest, where a failed test would show up as green. Which happens when you have a failed assert followed by a successful one in the same test function.
Also new: test adapter now uses package information (when available) to sort testcases into a tree, where before it would just show everything in a flat list.
Since you can run tests from any level in that tree, you can now run all tests from e.g. a second level package using just one click.
I’ve just released verion 2.0.0 of Haxe Test Explorer extension!
major changes are:
a switch to VSCode testing API
displaying execution times for test cases (only buddy, [hexunit(*)], munit and utest(**))
support for multi-root workspaces
(*) hexunit seems to round to full seconds, so execution times might not be very accurate
(**) requires current git version of utest or a future release
