VS2015 Test Explorer does not run all tests when in different namespaces

Bug #1480019 reported by Nick Moyle
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
NUnit Test Adapter
Invalid
Undecided
Unassigned

Bug Description

Under VS2015, when the Top level namespace of the classes holding nunit tests are different, but in the same project, the tests are found by Test Explorer, but not always executed. It appears to depend on which test is run first.

The Run All option is selected
The Playlist is set to All Tests
The Filter box is empty (well, says Search).
All tests are displayed in the Test Explorer
Only a portion of unit tests run.

You can set the Filter to FullName:"", and then all Tests will consistently execute.

There is no VS2015 documentation to indicate the default Filter, when one is not set, but it would appear that when there is no filter specified, that the nunit Adapter is doing something different.

A project with this issue can be found at https://github.com/fclp/fluent-command-line-parser.
Using this as the source, install the nUnit.Adapter from nuget

Load it up, hit Run All. On first compile all tests will be found and potentially execute. On subsequent re-runs, only those in the non-default namespace will run. If you change some code to force a new build, normally all tests will execute.

There are 4 classes in the FluentCommandLineParser.Tests.Internals namespace. If the CommandLineOptionFactoryTests.cs file is updated to the Fclp.Tests.Internals namespace, then all unit tests will run, even those that are in the non-default namespace. This behaviour makes it a little inconsistent, but makes me think that it is being affected by which tests are first executed.

description: updated
Revision history for this message
Charlie Poole (charlie.poole) wrote :

As indicated here https://launchpad.net/nunit-vs-adapter this project has not been actively developed on Launchpad for about two years. Please file bugs on Github: at https://github.com/nunit/nunit-vs-adapter for the NUnit 2 version or https://github.com/nunit/nunit3-vs-adapter for the Beta NUnit 3 version.

If you are currently using version 1.0, which was the last version published on Launchpad, you should upgrade to the latest stable version to determine whether the problem you are seeing still exists.

Changed in nunit-vs-adapter:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.