Khalid ⚡The release candidate for #JetBrainsRider 2024.2 with #xUnit 3 support. This should help #dotnet folks migrate their tests from v2 to v3. #tdd #bdd #tests
Vedran Mandić
//sebastian@khalidabuhakmeh @simoncropp @bradwilson does someone want to migrate #AutoFixture? I tried my best but get stuck at f.e. "AutoDataAttribute" and all other classes inheriting DataAttribute.
"DataDiscoverer" seems to be completly gone? and I need help with the changes to GetData ...
"DataDiscoverer" seems to be completly gone? and I need help with the changes to GetData ...
Brad Wilson@evilbaschdi @khalidabuhakmeh @simoncropp I can definitely help with that, but have you read the migration guide yet? I'm hoping most of your questions will be answered there (and if not, I can add what's missing): https://xunit.net/docs/getting-started/v3/migration
@evilbaschdi The TL;DR is probably this: there is no need for discoverers any more. The attributes are responsible for their own discovery. So whatever logic was in the custom discoverer likely just moves into the attribute.
@evilbaschdi I haven't looked yet to see if this affects AutoFixture, but I just realized that I inadvertantly removed access to the test method when discovering data, which I will need to restore: https://github.com/xunit/xunit/issues/2998
@bradwilson @khalidabuhakmeh @simoncropp I flew over it already and also had a look into the xunit repo but did not really get an answer for my problem ... but it was sunday 😄
@evilbaschdi I've fixed the missing MethodInfo problem, it's available in 0.2.0-pre.83 (via CI server).
I've updated the migration guide as well.
Let me know if there's anything else I can do to help.
@bradwilson update after weekend 🤘
Simon Cropp@bradwilson @evilbaschdi @khalidabuhakmeh any thoughts on how long you expect to be maintaining v2 (if at all) after the release of v3?
@simoncropp @evilbaschdi @khalidabuhakmeh As little as possible. Ideally zero v2 releases from this point forward.
@khalidabuhakmeh @simoncropp @bradwilson OK, it's building; I'm not sure if everything still works.
https://github.com/evilbaschdi/AutoFixture/tree/feature/xunit.v3
#AutoFixture
https://github.com/evilbaschdi/AutoFixture/tree/feature/xunit.v3
#AutoFixture
@khalidabuhakmeh @simoncropp @bradwilson
PR at #AutoFixture repo https://github.com/AutoFixture/AutoFixture/pull/1471
Discussion regarding PR at #xunit repo https://github.com/xunit/xunit/discussions/3006
☕ ☕ ☕
xUnit.net@khalidabuhakmeh If you install our project templates, they'll show up in the list, and things just run "out of the box":
@khalidabuhakmeh @bradwilson so i can run tests. but cant debug. rider just spins as if it is trying to start the debugger and cant
@khalidabuhakmeh @bradwilson and a Debugger.Launch(); doesnt work either
@simoncropp @khalidabuhakmeh I didn't try debugging. We currently depend on the implementation of `IRunContext.IsBeingDebugged` to return `true` when the debugger is running, and `IFrameworkHandle2.AttachDebuggerToProcess` to attach to it successfully. https://github.com/xunit/visualstudio.xunit/blob/6c726eb59eb687170b49cf442f68e2267a640db4/src/xunit.runner.visualstudio/VsTestRunner.cs#L604-L606
@simoncropp @khalidabuhakmeh Based on user feedback at https://github.com/xunit/xunit/issues/2987#issuecomment-2263491048 we will be switching to `IFrameworkHandle.LaunchProcessWithDebuggerAttached` (instead of attaching after the fact) before we RTW `xunit.runner.visualstudio` 3.0.0. https://github.com/microsoft/vstest/blob/b1e15e51243982a3396d0136f4fd889a707e1d0e/src/Microsoft.TestPlatform.ObjectModel/Adapter/Interfaces/IFrameworkHandle.cs#L30
Kirill Osenkov@bradwilson @simoncropp @khalidabuhakmeh good! launching under debugger is a much better experience because optimizations are turned off and you can actually see things! I always say only attach when you can't start under debugger.
@KirillOsenkov @simoncropp @khalidabuhakmeh It was literally a case of me being dumb and not realizing this existed 😂
@bradwilson @KirillOsenkov @simoncropp yeah it's a console app now so the process has to be launched in debugging mode.
@khalidabuhakmeh @KirillOsenkov @simoncropp This will definitely depend on the unit test runner in Rider/Resharper implementing the aforementioned interface methods/properties because we have no idea how to launch into your debugger (nor can we realistically special case all the runner hosts).
@KirillOsenkov @simoncropp @khalidabuhakmeh Slight hiccup: https://github.com/microsoft/vstest/issues/5171
IFrameworkHandle.LaunchProcessWithDebuggerAttached needs ability to control ProcessStartInfo · Issue #5171 · microsoft/vstest
Description I am trying to replace a situation with the xUnit.net v3 VSTest adapter where I launch the test project (out of process) and then attach via IFrameworkHandle2.AttachDebuggerToProcess wi...
@KirillOsenkov @simoncropp @khalidabuhakmeh (and by slight, I mean 100% unlikely to be fixed in a way that I can take advantage of)
@KirillOsenkov @simoncropp @khalidabuhakmeh I want to be more upset about this than I am, but it feels like this doesn't matter as much as you might think: if the user is asking to debug a test, then they're using a Debug build, and optimization is turned off for Debug builds by default.
Should I inject an `<Optimize>false</Optimize>` property via the xunit.v3.core .targets file, so that optimization always gets turned off? (Feels heavy handed, but thought I'd ask.)
@bradwilson @KirillOsenkov @simoncropp I just don't know who's running tests in an optimized mode AND debugging. It's a strange scenario from my perspective.