No tests shown in Test Explorer
diluculo opened this issue · 11 comments
Today I updated my local master with the latest origin/master. However, there are no tests in the Test Explorer of Visual Studio. I did followings:
git fetch upstream
git rebase upstream/master
and then run restore.cmd in the Command Prompt
Am I missing something? Is Expecto.VisualStudio.TestAdapter needed to be installed?
If you want to see running tests in The Test Explorer VS then yes you need it (I'm never used Expecto.VisualStudio.TestAdapter although). But you can run tests without it like console app.
I think Test Explorer makes our life easier. Is it possible to add the TestAdapter to the solution? I found this.
I've added the test adapter. The tests now do show up in the test explorer on my machine. Does that work for you?
I've noticed that the test project now takes quite some time to compile. Not sure why exactly, but it seems to correlate with the switch to Expecto.
at least, it doesn't work for me. Adapter couldn't find any suitable tests.
Even after rebuilding the test project?
In the Command Prompt, everything is OK. But at rebuilding on VS 2017 15.4.4, I got an error in the Tests Output: System.ArgumentException: An item with the same key has already been added.
Details of the error are here
Related issues may be #28 of adamchester/expecto-adapter and #425 of jbevain/cecil.
In theory this should not affect us, since we already use Cecil 0.10-beta7. I also cannot repro yet on my side (works for me after restarting VS and rebuilding the test project). I wonder what is different between our setups.
Switching to FCS (instead of the system installed F# compiler) could remove one potential difference; I intended to do that anyway.
I've just tried it on another machine and it worked as well, in VS 2017 15.4.4, 15.5 preview 4 (after installing the test tools) and also on VS 2015.
But at rebuilding on VS 2017 15.4.4, I got an error in the Tests
The same error
If the change to FCS doesn't not help, I may have to revert. For me, no longer needing a test runner in the fist place makes things more straight forward, direct and simpler (especially also looking forward supporting .Net Standard). But it is important that this works for all contributors.
When starting UnitTests, an Exception panel appears on the problematic line and I can edit it. For me, it is easy and much more intuitive.
