expecto
expecto copied to clipboard
haf
Rider Support?
Jetbrains has had the issue outstanding for 2 years now. https://youtrack.jetbrains.com/issue/RIDER-7172
Is there anything we can do on expecto's side to get stuff to work?
2nd. Would be very nice to have! Much needed, especially since Rider doesn't understand that let main argv is the last declaration in the compilation sequence:
@varon We've started working on adding Expecto support to Rider. It currently seems nothing needs to be added or changed in Expecto itself to get some initial tests running/debugging.
@auduchinok : It may be a lot to ask, but will it also allow us to see coverage? That could be very useful
@drhumlen There're chances it will be able to get it (almost?) for free the same way we didn't have to do anything to get coverage working in F#. If it only requires implementing some simple Expecto-specific components then it'll be easy to address. We'll see. :)
@auduchinok. Cool! :) Do you have any ETA? (I'm using EAPs whenever available)
@drhumlen No estimates to share for now.
If you want some status updates, here're a test session results for the Expecto dotnet template, after run/debug:
Now it needs more work in the discovery part.
Any progress on getting expecto integrated into Rider? Really love both :)
@ErikSchierboom Yes, most of pre-requirements on F# plugin side are ready. We need to finish integration of inner tests discovery and some other things. It's likely it all can come to 2020.1 EAP, though, no particular promises for now, since it also needs changes in Rider itself. :)
I'm suspecting that it's really hard for Rider to pinpoint the location of a test since Expecto by design is all about programmable flexible testing. With the other libraries, modules and their [<Fact>]-let bindings are unambiguously placed, but with expecto it can be anywhere.
If it doesn't make sense to add Expecto support to Riderr, that's ok. There are other more low-hanging fruits I'd rather have I think. 🤔
@fc1943s Sorry for no updates. We didn't move much forward during 2020.1 development cycle. Some of the changes on F# support side depend on a unit test infrastructure refactoring and it was postponed till 2020.2 AFAIK. I'm going to try working it around so in the worst case we could enable at least a limited support in 2020.2 if the unit tests refactoring is not done by that time.
Rider 2020.2 did some huge updates to the way testing is handled. @auduchinok do you know if this allows Expecto to work?
Edit: https://www.jetbrains.com/rider/whatsnew/#unit-testing
@varon Sorry for the delay. Yes, these changes were one of the most important things we've waited for in the plugin.
@lucasteles @marlinla @fc1943s @mdpedersen - Would be good if someone could give it a try.
Maybe things work now?
As of 2021.1 EAP9 Beta, there's still no support.
From Resharper release notes:
We’ve implemented support for VSTest adapters – a feature that allows you to discover and run tests from a third-party framework.
Unfortunately, Rider still won't recognise the test project. Note, this is listed in the Resharper release notes, so there may be some work still needed on the Rider side, and I'm jumping the gun.
Looks like we could be close though!
@auduchinok What blockers are remaining on this?
@C0DK Rider integration works for me with these two packages installed in the test project:
Microsoft.NET.Test.Sdk
YoloDev.Expecto.TestSdk
Did you try that?
above steps doesn't work for me targeting net7.0 with rider 2022.3 EAP9. I can do dotnet test from the solution dir, but sadly rider is showing me
Same for me with 2023.2 on .NET 7, Linux. I installed both
Microsoft.NET.Test.Sdk
YoloDev.Expecto.TestSdk
and enabled VSTest adapters support, but the discovery finds nothing.
I just tried with Windows and both .NET 7 and .NET 6.
Enabling VSTest adapters support it works perfectly!
I have VSTest adapters support enabled and the Expecto.Sample tests are not being discovered in Rider 2023.2 on Windows.
I also tried adding the *Sample* or *Expecto.Sample* mask which did not make a difference.
