AxoCover
AxoCover copied to clipboard
No tests found / support custom test assembly search paths
Using AxoCover 1.0.71.0 with Microsoft.VisualStudio.QualityTools.UnitTestFramework 10 in VS 2017 Professional on Windows 10 64-bit, AxoCover reports that it finds no unit tests in the solution. There is a unit test project in the solution and 228 tests run successfully if I open the VS Test explorer and click the "Run All" button. I tried loading tests in VS 2015 as well, but it also did not work.
I have noticed that a different solution worked as expected. This solution only had 15 unit tests, but they all ran. This solution was opened in VS 2015.
Thanks for reporting the issue. Based on that it also failed when you used VS2015, it is not related to VS 2017 specifically. Could you provide some more data:
- Can you check the output of AxoCover in the output window? Does it show any errors? (I have seen some exceptions when scanning for tests in telemetry coming in today, but I cannot know if it was you. The telemetry module prints the exceptions it collects in the output window - you need to select AxoCover there to see it)
- You mentioned that you use Microsoft.VisualStudio.QualityTools.UnitTestFramework 10 which is quite old, does it work with a later version?
You might give try the latest pre-release of xNUnitSupport branch fron GitHub (you can download the VSIX from the Releases tab), it uses a quite different solution for discovering and running tests, which might help your case. (It is somewhat unstable still though, soo your mileage may vary.)
I posted the telemetry error here: https://github.com/axodox/AxoTools/issues/19 Please check if you see anything similar in the output window.
There are no errors in the AxoCover output window. I did not have telemetry turned on yesterday but did turn it on today. I rebuilt the solution at 7:55 am EST so if you see errors at that time, it could be me. I also don't see any way to update the Microsoft Unit Test Framework. I tried using a NuGet package which was at version 11.0 but it wouldn't install because the target .Net framework is 4.6.2. I did see unit tests work on a different solution, so as of now, 1 out of 4 solutions I've looked at find unit tests and the other 3 don't. This is all using Visual Studio 2015. The one solution that works is also using version 10.0 of the Microsoft Unit Test Framework.
On Wed, Mar 15, 2017 at 6:15 PM, axodox [email protected] wrote:
Thanks for reporting the issue. Based on that it also failed when you used VS2015, it is not related to VS 2017 specifically. Could you provide some more data:
- Can you check the output of AxoCover in the output window? Does it show any errors? (I have seen some exceptions when scanning for tests in telemetry coming in today, but I cannot know if it was you. The telemetry module prints the exceptions it collects in the output window - you need to select AxoCover there to see it)
- You mentioned that you use Microsoft.VisualStudio.QualityTools.UnitTestFramework 10 which is quite old, does it work with a later version?
You might give try the latest pre-release of xNUnitSupport branch fron GitHub (you can download the VSIX from the Releases tab), it uses a quite different solution for discovering and running tests, which might help your case. (It is somewhat unstable still though, soo your mileage may vary.)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/axodox/AxoTools/issues/16#issuecomment-286896934, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0m6tj2GpEXewRvpUwhGy34lBK1t6SLks5rmGMdgaJpZM4MeWaC .
-- Brian
Can you create a small example project which causes AxoCover to fail test discovery and upload it in a zip here?
So I can reproduce your issue. (There were no issues reported by telemetry today so far.)
I did try to create a small test project but without luck (that is, everything worked). I'll try to determine the issue as I get time but I'll have to do it around other things I need to work on.
Brian
On Thu, Mar 16, 2017 at 8:08 AM, axodox [email protected] wrote:
Can you create a small example project which causes AxoCover to fail test discovery and upload it in a zip here?
So I can reproduce your issue.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/axodox/AxoTools/issues/16#issuecomment-287038113, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0m6uEg5SLvK32h-Y6rP9IIKNwS5er5ks5rmSZXgaJpZM4MeWaC .
-- Brian
Ok, no problem, if you download the source code, try debugging https://github.com/axodox/AxoTools/blob/master/AxoCover/Models/TestProvider.cs. This is the class discovering the tests, it is quite simple, and should show what goes wrong.
You will need Visual Studio SDK installed, or you could add the VSSDK nugget package to build (the latter needs VS2015+). Otherwise just open the solution and build.
So it seems we have a process that takes all build output and moves it to a specific folder. This is not a build event but some other method is used to move these files. Is there any way to specify the folder in which AxoCode should look for the test dll files?
On Thu, Mar 16, 2017 at 9:08 AM, axodox [email protected] wrote:
Ok, no problem, if you download the source code, try debugging https://github.com/axodox/AxoTools/blob/master/AxoCover/ Models/TestProvider.cs. This is the class discovering the tests, it is quite simple, and should show what goes wrong.
You will need Visual Studio SDK installed, or you could add the VSSDK nugget package to build (the latter needs VS2015+). Otherwise just open the solution and build.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/axodox/AxoTools/issues/16#issuecomment-287051139, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0m6lHuq892SxFY8U1KDjRp1K4A3lviks5rmTRIgaJpZM4MeWaC .
-- Brian
Not as of now, currently AxoCover uses the build target path queried from Visual Studio API. However I could simply add this to version 1.1 since it can store settings per solution.
You would get a new field on settings page like "additional assembly search paths", where you could browse to the directories and add them. I guess the name of the DLLs is the same as they are built, so we can check for them in these directories too. This would solve your problem.
I will update the issue title to correspond to this.