[ANN] VS Code Expect and Inline Tests extension

Ecosystem
1

Hi, I’ve just released a VS Code extension to integrate PPX Expect and PPX Inline Test to VS Code.
It also works in combination with Alcotest Test Explorer

Expect and Inline Tests
GitHub: VS Code Expect and Inline Tests

It always adds/updates/deletes expect and inline tests when opening or saving an OCaml source file. By default, it also runs all inline tests of all inline test runners to discover tests on startup. If this takes too long or you don’t like that, you can disable that behavior in the settings. The Refresh Tests button in the upper right of the Test Explorer view also runs all expect and inline tests to fill the tree.

8 Likes
2

Hi, a new version - 0.2.0 - of the Expect and Inline PPX extension with minor cosmetic changes is ready for you.

Expect and Inline Tests
GitHub: VS Code Expect and Inline Tests

I’ve also released a new version - 0.3.0 - of the Alcotest extension (with more substantial changes). See:

Changelog:

Version 0.2.0 (2023-03-06)

  • Remove unnecessary node ‘Expect and Inline Tests’ in the Test Explorer tree.
  • Change the name of the test profile to ‘Run Expect and Inline PPX tests’.
  • Add documentation of ‘Run Profiles’.
  • Add GitHub Issue Template.
3

Hi @Release-Candidate :slight_smile:

Thanks for your work on this, improving the test workflows on VSCode is much needed and super valuable! This brings the OCaml VSCode experience one step closer to the experience you can find with mainstream languages (e.g. Testing Python in Visual Studio Code).

This is actually something that we had discussed adding in the OCaml Platform VSCode extension. I’m curious to know if you considered adding this feature to the extension itself. And if you did and decided otherwise, what made you prefer to publish a separate extension?

2 Likes
4

Thanks for your kind words.

The main reason why I hadn’t added both (for the existence of the expect/inline extension @lukstafi is to blame :wink: extensions to the Platform extension was because it is written in OCaml and I haven’t had any experience in writing VS Code extensions or OCaml for JS/Node (and not much writing OCaml, I’m just trying it now because of multicore and effects), so I thought I could at least use the ‘native’ language for extensions to make the process a bit easier and faster. And my plan was to write a testing extension for Purescript too, so OCaml would have been a bad fit for that (and Purescript for a OCaml extension :wink: . Also not supporting OUnit tests in the ‘official’ OCaml extension would look like discouraging its use.
The main advantage of integration in the Platform ext. would be running Dune in the same environment/sandbox. Running all tests in one extension also would make coordinating dune processes easier (because of the lock).
Last but not least the biggest problem of the Alcotest extension (inline - Alcotest and JS - and expect tests are sufficiently unique) is finding the test cases reliably in the source, which should be easier being able to use existing OCaml libraries, I guess. Porting the extensions to OCaml and integrating them into the Platform should be quite straightforward. But as the weather is getting warmer, the snow melts and the days are getting longer I’m getting less inclined to spending much of my spare time in front of the computer too.

I do not in any way want these extensions to be ‘mine’, so this is has not been part of the decision to not contribute to the Plattform extension.

1 Like
5

This was what I have been looking for! :slight_smile: Thanks!

6

The main reason why I hadn’t added both (for the existence of the expect/inline extension @lukstafi is to blame :wink: extensions to the Platform extension was because it is written in OCaml and I haven’t had any experience in writing VS Code extensions or OCaml for JS/Node (and not much writing OCaml, I’m just trying it now because of multicore and effects), so I thought I could at least use the ‘native’ language for extensions to make the process a bit easier and faster.

It’s funny you’re mentioning that the reason for not contributing was that you didn’t have enough experience with OCaml: one of the motivations for writing the extension in OCaml is that we thought we’d have more community contributors if the code was written in OCaml!

That being said, if you’re interested in contributing but the barrier to doing so was too high, don’t hesitate to ask questions on the issue tracker. I’m also happy to help, feel free to reach out at thibaut.mattio@gmail.com.

Last but not least the biggest problem of the Alcotest extension (inline - Alcotest and JS - and expect tests are sufficiently unique) is finding the test cases reliably in the source, which should be easier being able to use existing OCaml libraries, I guess. Porting the extensions to OCaml and integrating them into the Platform should be quite straightforward.

I’m not aware of libraries that would make the integration easier, but it would certainly be interesting to explore how we could make Dune aware of the tests, it would make it possible to run a single test easily from the command line (e.g. dune test my_test.ml:54, see running a single inline test · Issue #4873 · ocaml/dune · GitHub) and expose them from Dune RPC for consumption from the editor extensions. cc @emillon who’s been thinking about this I think.

Porting the extensions to OCaml and integrating them into the Platform should be quite straightforward. But as the weather is getting warmer, the snow melts and the days are getting longer I’m getting less inclined to spending much of my spare time in front of the computer too.

Completely understandable! Again, you’re more than welcome to contribute, and I’m happy to help with any blocker you have - but otherwise, we’ll probably explore adding the support for a test explorer at some point, and will let you know when that happens.

Regardless, your work on this is really appreciated, and I have to say I’m rather impressed that the first thing you do while trying OCaml 5 is identify missing features in the VSCode extension and take it on you to build new extensions! Thank you :slight_smile:

2 Likes
7

It mostly because of JS_os_OCaml und the interop with VS Code and Node. Had it been ‘normal’ OCaml I wouldn’t hesitate. But having tried some to-JS compilers I know that interop with JS can be quite a PITA, ES modules vs. CommonJS modules for node can be just enough of a hassle.

And thanks for your offer, as it’s only a question of time when I’ll add the extensions to the OCaml platform.

Running a single inline test would actually be quite hard for dune, as it needs to know if it is an Alcotest inline test or a JS inline test and call the test runner with the correct command line. Or if it just passes the test arguments through to all runners, but then the command line for a single Jane Street test would be

dune test inline-test-runner LIBRARY_NAME -only-test my_test.ml:54

vs. Alcotest:
Yes, two times test and ID is not the line but the index of the test in the list of tests in the same file.

dune test test my_test.ml ID

I’d gladly help.