Introduction

When Visual Studio 2013 fails to discover tests, the test code is often fine and the environment is not. Discovery problems in that era usually come from framework mismatch, missing adapters, or a test assembly that builds differently from what Test Explorer expects.

Start With the Framework and Adapter

Visual Studio 2013 can discover MSTest tests directly, but NUnit and xUnit usually need the right adapter or extension. If the adapter is missing, the project can compile cleanly and still show an empty Test Explorer.

A minimal MSTest example looks like this:

1using Microsoft.VisualStudio.TestTools.UnitTesting;
2
3namespace CalculatorTests
4{
5    [TestClass]
6    public class AddTests
7    {
8        [TestMethod]
9        public void Add_TwoNumbers_ReturnsSum()
10        {
11            Assert.AreEqual(5, 2 + 3);
12        }
13    }
14}

For MSTest, verify that:

• the project references the MSTest assemblies
• the class has [TestClass]
• the methods have [TestMethod]

For NUnit or xUnit, also verify the discovery adapter version actually supports Visual Studio 2013. Newer package versions are not always backward-compatible with older IDEs.

Make Sure the Output Assembly Is a Real Test Library

Test discovery only works against the built test assembly. If the project outputs the wrong kind of artifact, or is skipped in the active build configuration, Test Explorer may have nothing valid to inspect.

The safe baseline is:

• test project type is a class library
• target framework is supported by the chosen test framework
• the project builds in the active solution configuration
• the DLL appears in the expected bin folder

If you are unsure, rebuild the solution and inspect the build output carefully. Discovery issues are often just build issues wearing a different costume.

Keep the Discovery Surface Simple

Older tooling is less forgiving than modern tooling. If discovery is failing, reduce the project to one explicit, public test class and one explicit, public test method. That removes ambiguity about attributes, visibility, inheritance, and runner support.

For example, this is a safe starting point:

1using Microsoft.VisualStudio.TestTools.UnitTesting;
2
3namespace SmokeTests
4{
5    [TestClass]
6    public class DiscoverySmokeTest
7    {
8        [TestMethod]
9        public void TestExplorer_ShouldFindThisTest()
10        {
11            Assert.IsTrue(true);
12        }
13    }
14}

If Visual Studio still does not discover this, the problem is almost certainly outside the test logic itself.

Check for Version and Extension Conflicts

Visual Studio 2013 sat in an awkward period where extensions, adapters, and NuGet packages did not always line up cleanly. A project copied from a newer solution can easily reference packages that build but do not participate correctly in old discovery tooling.

A few practical checks help:

• compare adapter versions with the supported Visual Studio version
• disable or remove conflicting test extensions
• try opening the IDE in safe mode

devenv.exe /SafeMode

Safe mode is useful because it strips out extension interference. If discovery starts working there, the test project may be fine and an extension is the real problem.

Clear Stale Build Artifacts

Sometimes the test explorer is looking at stale state rather than the current build. Close Visual Studio, delete the project's bin and obj folders, reopen the solution, and rebuild. This is low risk and often faster than chasing configuration theories for an hour.

It is also worth confirming that the test DLL being loaded is the one you just built, especially in larger solutions with several similar test projects.

Common Pitfalls

• Using NUnit or xUnit without the adapter needed for Visual Studio 2013 discovery.
• Mixing attributes from different test frameworks in the same project.
• Letting the project build as something other than a discoverable test class library.
• Assuming the test code is wrong when the actual issue is an unsupported adapter version.
• Ignoring stale bin or obj output and debugging the wrong assembly.

Summary

• Test discovery in Visual Studio 2013 depends heavily on matching framework, adapter, and IDE version.
• Start with one minimal public test and verify the project builds as a class library.
• Make sure the correct adapter is installed for NUnit or xUnit.
• Use safe mode and cleanup of build artifacts to rule out extension and cache problems.
• Treat an empty Test Explorer as a tooling configuration problem first, not a code problem first.