-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support .NET Core #313
Support .NET Core #313
Conversation
My concern would be running tests targeting 2.0, 3.5, 4.0 under those runtimes. Current adapter does that. It looks like this will not be available, although I may be wrong. Unfortunately, it's not something the unit tests tell us. |
Well, that was a lot of checkins getting this building and producing a NuGet package artifact, but this is now one step closer to being ready. I have added a list of remaining tasks that need to be dealt with before this PR is merged. The one I could use the most help with is figuring out why the |
|
In your list of test projects above using different frameworks, I didn't see anything mentioning multi-targeting. I think that an NUnit test project that targets multi frameworks should probably be supported. If I'm writing a library that uses multi-targeting, I'd like the tests to run against each target as well. In my initial testing, it does appear to work when run with "dotnet test". I just took a NUnit test project and changed from It's not working in VS, but I'm pretty sure VS is known to not support multi-targeting tests. So not much you can do about that. Anyway, I just thought you might want to add this use case to your set of tests. Thanks, |
@brantburnett: In my experience, reordering the target frameworks so that |
@brantburnett I use this when I need create an interpolable class library, for example, that will be run in both frameworks (NetCore and NetFramework). But in my opinion, when do you need test different frameworks the best practice is create 2 projects with different target framework and run tests from there... |
…am and changes based on the engine code review
@OsirisTerje has finished his code review via email. Thank you @OsirisTerje. Based on our conversations, we decided to revert back to version If anyone else would like to review this, please do so today. I plan on merging this evening and doing an alpha release to NuGet. Before that, I am going to pull the recent changes and give them one last test and start writing some documentation on how to use this in .NET Core projects. |
Thank you very much @rprouse ! |
Thank you all for adding this feature! |
Hi, This is brilliant, many thanks! I've just successfully run a set of tests on a project which dual targets netcoreapp1.1 and net45. It runs all the tests fine (256 tests on net45, 153 on netcoreapp1.1), and from a very quick look it supports debugging the selected tests etc. just as before too. I did note that if I am using multi-targetting with, e.g. I am on Visual Studio Professional 2017 15.0.0.0+26228.9 Also, I was previously building and targeting this project against net40 upwards, but it looks as if the dependency on Microsoft.NET.Test.Sdk v15.0.0 means that the lowest .NET Framework version I can test this way is net45, because if I try to target net40 I get:
|
@mikebeaton that does seem to be an unfortunate limitation of multi-targeting with the new CSPROJ format. AFAIK, |
For anyone who wants to start working with the new test adapter, I have written a blog post covering it's usage. Once everything settles down, I will migrate the core info into the docs, but for now, instructions are at http://www.alteridem.net/2017/05/04/test-net-core-nunit-vs2017/ |
Found another slight quirk (I saw this last night, but thought it might help if I replicate it and report on it this morning). If I have the 3.7 VSIX and the 3.8-alpha NuGet package both installed (I do realise this is a non-supported configuration, although I suppose it's quite easy to get there by mistake...!) then, when I test a netcoreapp1.1 target, it uses the 3.8 test engine (
), but if I test a net45 target, it uses the 3.7 test engine (
). These are each from exactly the same multi-targetted solution, using new format .csproj files throughout, so I'm not qute sure what's going on! |
@rprouse I think after all the hard (and very much appreciated!) work, you may have posted the wrong link above (?!), should be http://www.alteridem.net/2017/05/04/test-net-core-nunit-vs2017/ ? :) |
@mikebeaton thanks for pointing out the bad link. I've fixed it in my comment. |
(Hi. I was still trying to understand what happened as reported in my comment 3 above this. I think if I'm understanding it correctly, then it is that NUnit 3.7 can support new .csproj files, as long as Microsoft.NET.Test.Sdk 15.0.0 is installed, but not for .NET Core? Sorry - I know this is not a bug or an issue as such!) |
@mikebeaton when Visual Studio attempts to find tests in a project, it asks each installed VSIX and NuGet adapter in turn if they can run the tests and I believe it stops asking when it finds an adapter that works. So, it looks like VS asks the VSIX first. For .NET Core tests, the 3.7 VSIX will not run the tests, so it moves on until the 3.8 NuGet package runs them. For .NET 4.5, the 3.7 VSIX can run them so it does and the 3.8 never gets a chance. Unfortunately, VS doesn't see a NuGet adapter as newer than the installed VSIX. To VS, they are different things. |
I can confirm this, wrote about it back in 2013, https://blogs.msdn.microsoft.com/visualstudioalm/2013/06/11/part-3-unit-testing-with-traits-and-code-coverage-in-visual-studio-2012-using-the-tfs-build-and-the-new-nuget-adapter-approach/ saying "One thing to be aware of is that the VSIX adapter takes precedence over the NuGet adapter, if you have both installed. Even if you update the NuGet adapter to a later version than the VSIX, the VSIX will be used. That means you might run on an earlier version of the adapter, whereas TFS Build and developers who don’t have the VSIX will use the newer NuGet version. " Neither MSTest2 nor XUnit delivers their adapters as VSIX, and my guess (un-informed and unconfirmed) is VSIX test adapters are not going to get much support from MS moving forward. The recommended approach should be to add the nuget adapters to all solutions and uninstall the vsix from all devs machines. |
Dear both, Many thanks for confirmation of this. For me, it wasn't so much that the VSIX gets precedence, I can see from an engineering point of view why VS might not be expected to know that that the VSIX and NuGet versions are the same thing, but rather I wasn't expecting to see 3.7 running tests from new format .csproj files at all! :) |
@mikebeaton other than the way that we package it, the full .NET version of the adapter in the alpha is the same as the 3.7 adapter, so it isn't too surprising that it works. |
Yes! It was more the parsing of the csproj file that I was surprised by, not the executing of the tests in .NET Framework - I think I'd got confused and thought that the issue being addressed by the update was support for the new csproj format as well as support for Core, but obviously not. :) Thanks again for all this work. |
Do Not MergeFixes #297
Starting a PR so that people can easily find the most recent AppVeyor NuGet feed builds for testing. This produces a NuGet package. It currently does not produce a VSIX. I have also up'd the version to 4.0 because these are major changes. It isn't inline with our original plans for 4.0 which included running NUnit 2.x tests, so feel free to object to the version.
These changes require that the new
dotnet
CLI and the .NET SDK to be installed and only builds in Visual Studio 2017.Work still to do,
dotnet test
is not workingbuild.cake