Hi @Nsidorenco - Great work on this so far! I'm very limited on free time at the moment (essentially I have none!) so this is a big help towards improving this adapter. When I get chance, I'll take a good look at the changes, but at first glance, it looks like it's going in the right direction.

@Issafalcon just take your time 😄 Outside of testing it is relatively feature complete now and should be ready for a review

I'm willing to help out with this. I went down a similar rabbit hole with my test project being too large causing me to create this PR #120

I swapped over to your branch and I'm getting the following error.

Seems to be due to this line here. https://github.com/Nsidorenco/neotest-dotnet/blob/6a1329bf0f5bdcb2b897645c5c804448a94817e2/lua/neotest-dotnet/vstest_wrapper.lua#L84C5-L84C70

When I get rid of some of those debug lines on my end, the test seem to attempt to load based on the debug messages.

It seems like it's failing to parse and keeps retrying? It's a little unclear.

I'm using C# on Windows 11

neotest-broken.log

• I get no test populating

neotest-working.log

• All of my tests are populating and working

neotest-partially-working.log

• Only the test for the first test file showed up and nothing else worked
• Two instances of neotest-dotnet showed up in the summary window as well

All of my projects are setup exactly the same. The solution is in the same spot, the projects are named very similarly. The structure of the projects are exactly the same as well

@Nsidorenco I didn't see you made another commit after your message as I was gathering logs. Here is an updated log on the one that doesn't work. This time around it never got past the parsing tests phase after 5 minutes. I don't know if it would have finished though

neotest.log

Edit:

Looks like it isn't loading tests for the working project either now

From the logs it seems things are running at different times compared to when I use the adapter, e.g. for me the adapter filters the directories (which triggers test discovery for the whole solution) where in your case it seems to trigger test discovery for a single file before running the directory filtering.

That in itself is a little curious but not really enough to tell what is wrong.

In the logs for the broken solution there are passages like this:

TRACE | 2025-03-12T13:37:30Z-0500 | ...azy/neotest-dotnet/lua/neotest-dotnet/vstest_wrapper.lua:88 | neotest-dotnet: Discovering tests for: C:\Users\wayneb\source\Services\CheckIn\CheckIn.Tests\bin\Debug\net8.0\CheckIn.Tests.dll

TRACE | 2025-03-12T13:37:30Z-0500 | ...azy/neotest-dotnet/lua/neotest-dotnet/vstest_wrapper.lua:88 | neotest-dotnet: Discovering tests for: c:\Users\wayneb\source\Services\CheckIn\CheckIn.Tests\bin\Debug\net8.0\CheckIn.Tests.dll

TRACE | 2025-03-12T13:37:30Z-0500 | ...azy/neotest-dotnet/lua/neotest-dotnet/vstest_wrapper.lua:88 | neotest-dotnet: [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v3.0.2+dd36e86129 (64-bit .NET 8.0.13)

TRACE | 2025-03-12T13:37:30Z-0500 | ...azy/neotest-dotnet/lua/neotest-dotnet/vstest_wrapper.lua:88 | neotest-dotnet: [xUnit.net 00:00:00.25]   Discovering: ServiceHelper.Tests

TRACE | 2025-03-12T13:37:30Z-0500 | ...azy/neotest-dotnet/lua/neotest-dotnet/vstest_wrapper.lua:88 | neotest-dotnet: [xUnit.net 00:00:00.55]   Discovered:  ServiceHelper.Tests

TRACE | 2025-03-12T13:37:30Z-0500 | ...azy/neotest-dotnet/lua/neotest-dotnet/vstest_wrapper.lua:88 | neotest-dotnet: Wrote test results to C:\Users\wayneb\AppData\Local\Temp\nvim.0\kzBJ3b\18

DEBUG | 2025-03-12T13:37:30Z-0500 | ...cal/nvim-data/lazy/neotest/lua/neotest/lib/file/init.lua:23 | Reading file: C:\Users\wayneb\AppData\Local\Temp\nvim.0\kzBJ3b\18
DEBUG | 2025-03-12T13:37:30Z-0500 | ...cal/nvim-data/lazy/neotest/lua/neotest/lib/file/init.lua:23 | Reading file: C:\Users\wayneb\AppData\Local\Temp\nvim.0\kzBJ3b\19

Could you try and open the files listen and see what the content is? I would expect one of the files to contain a json object of all tests in that project

It looks like there are some files in that folder that contain all of the tests. What I'm noticing though is this.

For all of my solutions, I have one test project for the shared project I use throughout all of my programs and another test project for that particular program. It looks like only ever loaded in the tests for that shared project.

After removing the reference to the shared project's test, it looks like none of the files have any tests populating. There's currently 31 files in here and they either have 1 or {} in them

@waynebowie99 I have a suspicion this might be caused vstest returning paths with windows style separators, but the neovim api always returns unix-style path separators.

I have tried to convert all paths to the unix-style in the latest commit. Please see if that made a difference for you!

Looks like it's working better than it was now! I am getting test populated, eventually. I'm not sure why it takes multiple minutes for tests results to show up. I had one case where it took around 20 minutes.

For the most part, it seems to be loading all of the tests but I am still running into some issues with not all of the tests are showing up. I wondering if this is related to the long discovery phase I'm facing?

@Nsidorenco Do you think some of my problems could be tried to multiple dotnet build operations trying to start? Whenever I open up the test summary page to start parsing tests, I get a random multiple of error messages indicating the build failed. Even though I know the build works. I also see multiple dotnet host processes spawn in Task Explorer

The highlighted one is from roslyn.nvim but the rest were spawned by the test parse from what I can tell

@waynebowie99 That's a very good idea! We are being pretty wasteful trying to build all the projects when we have access to the solution file. I'll try and see if I can get a version working were we only build the solution file.

@waynebowie99 I tried to optimize the building, so it only build the solution once at startup.
It does however try to repeatedly build a project if it fails to compile, which I'm not sure is the most ideal behavior but I think its good for now.

I also fiddled with the concurrency of test discovery, so please check if this has improved things for you!

On my end, it just works™️. Even works perfectly fine with custom dotnet_additional_args that override the --filter

Thank you for your work 🙏

@Nsidorenco It seems like it is better at locating some tests now. The current problem is that it seems to only load the tests from one file, maybe even the first one it finds? I also notice my computer isn't spinning up a bunch of dotnet processes anymore either

This ProgramShould test is the only one that is populating but it is not populating correctly

This is how the test looks like in my main project but this is the only test I have that has a base class which includes a few additional tests

These are the tests that are populating and running correctly

After doing even more digging I have more info. My other project I have includes a solution so technically if you a recursively looking for a solution, you find one initially and in a sub folder another is found. After removing the other solution more all of the tests are loading for ProgramShould, just in a weird way

Even more info. After opening a new instance of nvim, it looks like I'm back to the original 4 tests being loaded and not the 6.

I just tried removing a secondary test project I have for that shared project and that did not improve things.

That additional BidExtensionsShould.cs is not loading. I just tried removing ProgramShould and just having that other test in the root folder and now no tests are loading. The project file does show up though

I'm wondering if the test discovery phase is ending prematurely?

@Antomon0 Are you running on Windows? Any additional info would be a great help!

@Nsidorenco I might have figured out the problem. Seems to still be due to Windows paths having a back slash(). I look through the logs and there were still a few places that was using a forward slash(/) in the path and I think that was confusing the test discovery phase.

I did a very crude find/replace here and now I'm watching the and I'm seeing each of my test files pop up with various tests being discovered

@waynebowie99 really great work digging into this!
Does your fix of replacing slashes with backslashes make it so that you discover all test-cases as expected?

The windows vs unix paths have been particularly tricky.
vstest returns all paths in the style of the system, but according to the neovim api, all neovim file functions always returns paths with the unix style. But that must not entirely be the case, or I am missing some filepath normalization somewhere.

I don't have a windows machine to play around with, so your experimentation is super helpful!

@Nsidorenco Yes! It does discovery test in all of my various test cases I've been using. The only thing that is not working right now is running being able to run the test file or the nearest test. I'm not sure exactly why as I'm able to go to the test and even the status of the test shows in the gutter column fine. My assumption is that there are more unix paths being used somewhere down the line

That's encouraging!
There's quite a few places where we get file paths from different sources, so it would be nice to get a proper abstraction for dealing with file paths, so we can hopefully avoid "hacks" like replacing slashes with backslashes etc.

@waynebowie99 Is it only if when you try to run the nearest test it fails? I. e. can you run the tests from the summary pane?

Looks like this version has improved my experience quite a bit. I am getting tests found and am able to run them. TestNearest sometimes works but it's been working more times than not for the project I'm currently working in. It also seems like new tests are being found when they're added

I'll try paging through the logs to see if I can find anything weird still

I think I figured out why we've been having so many issues with the file path.

The vim.fs.normalize function will replace a windows path like C:\Users\wayne with C:/Users/wayne. This path would work fine with modern Windows. The problem is with some of the caching you're trying to accomplish by comparing the file paths. The dotnet test script is returning paths with backslashes(windows style) and not with forward slashes.

Frankly, I don't see why this would be the cause to any problems but that's my only assumption as it works for those in a non windows environment