Add support for F#

[ChristophSchmidpeter]

I would really like to use neotest for F#.
I am willing to extend the code for F#. However I have trouble debugging the lua code: The multithreaded nature makes it hard to debug. Now I also cannot get the lua debugger to work at all.

Can you point out what needs to be modified? And how do you debug the code?

[Issafalcon]

Hi @ChristophSchmidpeter! That's great you want to contribute. Especially as I know nothing about F#!

To debug, it's true that I haven't yet found a way to debug the asynchronous tasks in multiple threads. I've always had to resort to either sticking in print(...) statements, using the neotest logger in the async code, or writing unit tests to try and debug issues with the adapter.

I use https://github.com/jbyuki/one-small-step-for-vimkind to debug non-async stuff, but I'm afraid I've not found a way to get it working with mulithreading I'm afraid.

The thing that was a blocker before, to add F# support, was that there wasn't a suitable treesitter parser for it yet (which neotest relies on to get the test positions / names/ parameters etc). However, I've just noticed https://github.com/Nsidorenco/tree-sitter-fsharp has had a bit of work put into it, so it might now be functional enough.

As for getting this working, the adapter uses a treesitter discovery mechanism to find attributes specific to a particular test framework in c# (nunit, xunit, mstest). If you look in the discover_positions method of init.lua, you should see how it checks to see which framework is in use for a test file based on the attributes unique to that framework.

From there, it relies solely on treesitter queries to extract test names and positions in order to send those to the dotnet test command to run. The output of the test run is stored in a trx file, and then each test name is compared to that result file to get the errors or successes, and combines them into the final output in terms of a tree that neotest core understands.

I have no idea what test frameworks are available for F#, and I can only assume that you can still use dotnet test to run them, but you would first need to create those separate strategies and treesitter queries for determining which test framework is being use (for F# treesitter parser) and then extract the test names and parameters for the individual tests using treesitter.

All that said see my latest comment in #41. Test discovery can be improved for some frameworks by using the test runner and combining that with treesitter output for positioning, so I am planning on making some quite significant changes to how it might work for some frameworks. If possible, this might also be a good strategy for the F# side of things too, but first it would be worth doing a proof of concept to see if the treesitter parser is good enough.

[WillEhrendreich]

now the tree-sitter is at https://github.com/ionide/tree-sitter-fsharp

[WillEhrendreich]

dotnet/fsharp#14527
talked about here