I have a xUnit.net Test as follows:
static class MyTestClass
{
[Fact]
static void MyTestMethod()
{
}
In my case, in order to see any tests, I had to complete the following steps:
(All installed through NuGet Package Manager)
xUnit
v2.0.50727xUnit.extensions
v2.0.50727I'm using Visual Studio 2013 Premium. (Resharper NOT installed)
From http://xunit.github.io/docs/getting-started-desktop.html#run-tests-visualstudio:
If you're having problems discovering or running tests, you may be a victim of a corrupted runner cache inside Visual Studio. To clear this cache, shut down all instances of Visual Studio, then delete the folder %TEMP%\VisualStudioTestExplorerExtensions. Also make sure your project is only linked against a single version of the Visual Studio runner NuGet package (xunit.runner.visualstudio).
TL;DR your Test Classes must be public
(but your Test Methods can be private
and/or static
)
For reasons of efficiency, the xUnit authors have opted to not use BindingFlags.NonPublic
when searching for Test Classes in the runner (the MSIL metadata tables don't index private
(/internal
) classes to the same degree hence there is a significant performance difference in the relative efficiency that Reflection can thus achieve).
As a result of the above, the fact that your class
is private
means it doesn't get picked up.
The fact that the Test Method is private
and static
is fine - xUnit by design since 1.0 has supported both those aspects.
Note that the Visual Studio xUnit Runner extension, xunit.console.exe
(and the GUI), the xunit
MSBuild task, Resharper and CodeRush are all consistent in honouring this (although arguably they [especially the latter two] could do more to flag when a Test Class (i.e. class [potentially indirectly] containing Fact
-derived annoations) is private
).
The reason TestDriven.net runs your test is that the Author of TestDriven.net has put great effort into making it Just Work. It internally uses a special Test Runner wrapper/shim (termed the Adhoc Runner) to run your test. Be aware that the method is actually not being run via the xUnit.net runner and hence any attributes you put on your test that have side effects will not be triggered.
Notably NUnit (and I'm pretty sure MSTest) do use private reflection [and hence pick up tests in private
classes] which is probably why it never seemed an important thing for you to worry about before.
Note: A side effect / trick enabled by this is that you can make a Test Class private
as a quick way of Skip
ping all tests in a Test Class [and any nested classes]. (Sadly the cases on this planet of this being used unintentionally vastly outnumber the intentional cases of this though!)
(As referred to by @Kyle in the comments on the other answer) The same No tests found to run
message can result from using NuGet to get xUnit.dll and ending up with version 2.0.0 (which is currently marked as prerelease as some core functionality like discovering of v1 tests etc. has yet to be implemented in that branch).
The resolution in this case is to select Stable Only versions (as opposed to Include Prerelease) in the NuGet package manager.
I had the same issue in VS2017 RC, .NET core 1.1 project. Updating xunit.runner worked for me,
Install-Package xunit.runner.visualstudio
For me, the combination of my test class and test method names were too long; xUnit appears to have some cap on this combination.
Shortening the name of just the test method allowed xUnit to discover that single test. Shortening the name of the entire class allowed xUnit to discover all tests in the class.
Threshold of class name + method name appears to be 172 characters.