I’ve just released a VS Code extension to integrate Alcotest and inline Alcotest tests with VS Code.
It supports multiple workspaces/folders and uses the ‘native’ Test Explorer of Code, not the Test Explorer UI extension.
OCaml Alcotest Test Explorer extension
It only discovers tests when the extension is started or a test is run, no file watching (I don’t like extensions doing this on their own). I’ll add a ‘refresh’ button to the Test Explorer view, I guess, sometime.
The output of Alcotest’s list of test cases is used to populate the test tree, so this is always in sync with the tests the runners ‘know’ of. My compromise is the mapping of a test case to its source location, I just grep for the test case name (which can be truncated by Alcotest) in source files and pick the first match - which can be off from the ‘real’ location. I personally prefer having a correct Test Explorer tree to having a correct source location. In my experience with other test extensions sometimes both the tree and the source locations are incorrect.
- Currently it only works with dune, to run the test runners and because dune files are parsed for the name of the test runners. So my question is what it would take to make it work with other build systems. Making the commands to compile and/or run a test runner and the paths to search for test runner executables configurable is easy. Making the parsing of arbitrary build files for the right targets configurable is less easy, if it is feasible at all. Of course you could always fork of the extension to exactly fit your needs
- the extension just calls dune in the root of each workspace and it does the right thing with my projects. My question is if the right environment (sandbox) is used automatically when using the OCaml Platform extension?
- Would add disabling the grepping for the source locations make sense for you? So you just use the (correct) test tree to start and filter tests and not waste time searching through all source files, which could take too long and doesn’t give the correct result anyway.
The extension should also be quite easy to adapt to other testing frameworks (inline test runners), as long as they support some kind of list test command line argument.
And sorry, the link to Alcotest is broken in the README, I’m going to fix this is the next release.