One click debugging of xunit adapter in VS

[nohwnd]

https://github.com/xunit/visualstudio.xunit/blob/main/BUILDING.md#debugging

This section in debugging shows how to debug xunit under vstest. I've made some big improvements there, and we have a tool that allows automatic attaching of VS. Additionally it also allows attaching multiple processes to the same VS, and it does everything without prompting, unlike Debugger.Launch.

I don't know what your development flow is @bradwilson or how often you need to manually attach to testhost, so before I go any further with this, here is a little demo. Please let me know if you'd like to pursue this further :)

What you see is that I run dotnet test, and vstest.console attaches to VS and stops on the default breakpoint (can be disabled and hit yours directly), and then, if you continue the execution, testhost is attaching to the same instance of VS.

In the demo the first VS instance is used, but normally it walks up the tree of processes to find parent VS of the current process, so if you have a console app project that sets the variables, references your adapter and starts dotnet exe, you get one click debugging experience in VS.

In vstest we have such setup here:

https://github.com/microsoft/vstest/blob/main/playground/TestPlatform.Playground/Program.cs

I was trying to do the same thing in xunit.visualstudio solution, but I am getting a lot of build errors even on main, so I don't know if my VS is just being too picky today, or you don't normally use it. The commandline build worked just fine for me.

And you can also find source code there for the AttachVS tool, in case you don't fancy running random executables downloaded from internet. 😄

xunit.playground.zip

[bradwilson]

@nohwnd Due to dotnet/sdk#22469 Visual Studio is completely broken for this project now. So debugging instructions are irrelevant until that issue is resolved.

[bradwilson]

This issue was opened in xunit/visualstudio.xunit so I assumed this was about debugging the Visual Studio adapter, but this appears to be about debugging xUnit.net itself. Is that correct?

I generally don't debug v2 of xUnit.net itself. The most common thing that needs to get debugged is the assertion library, which I debug on v3. I don't need special steps for that, because v3 test projects are executables, so you just set the test project you want to debug as the startup project and hit F5.

[bradwilson]

@nohwnd Is my assessment above correct? If not, how would you envision this being used?