6

I'm struggling to get my unit tests to work. I've wrestled with this issue for several hours now, and I have no explanation as to why things don't work. I had a fairly major refactor on my codebase and have since gone through and fixed all the unit tests. The test project builds, it outputs a new unit test dll. However, when I go to run the tests in the test explorer, I get this message:

[2/27/2019 5:08:05 PM Warning] [MSTest][Discovery][C:\pathtotest.dll] Failed to discover tests from assembly C:\pathtotest.dll. Reason:Could not load file or assembly 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

[2/27/2019 5:08:05 PM Warning] No test matches the given testcase filter FullyQualifiedName=<namespace.namespace...testmethod> in C:\pathtotest.dll

Here is what I know:

  • I recently updated Visual Studio (within the past two weeks, don't remember exactly when I did it).

  • All packages in the test project have been updated and are running the latest versions of things.

  • I have another unit test project that is .Net Core 2.1, this is .Net Framework 4.7.2. The other project works.

Some suggestions other posts give are to make sure your test architecture is correct and to delete a folder in %TEMP% (don't recall the exact name, except is was something about VisualStudioExtensions). The folder they suggest to delete was not found in %TEMP% and I tried running my tests on both architectures with the same result.

So the next step was to take a sanity test and make sure the built test dll exists. It does.

At this point I'm about ready to just start a new test project and copy paste over all the tests one by one and see if maybe one is throwing a silent error. I can't find any useful information with my own Google-fu skills and I'm hoping someone has some useful insight or tricks to try.

Community
  • 1
  • 1
Zulukas
  • 1,180
  • 1
  • 15
  • 35
  • Check each and every dll using if it included or not. this is your problem `C:\pathtotest.dll`. is this dll has a dependencies to other dll? – Vijunav Vastivch Feb 28 '19 at 03:13
  • Which nuget you have in this project? Do you have the **runner** nuget? – baruchiro Feb 28 '19 at 04:26
  • Not entirely sure what you're asking @Baruch. When I initially created the project, it was just a .Net Framework MSTest project. – Zulukas Feb 28 '19 at 16:42

4 Answers4

3

From the comment above:

Using this C:\pathtotest.dll

Check also if it 32bit or 64bit runtime.

Most cases are using 32bit dlls.

Hope it helps

Vijunav Vastivch
  • 4,153
  • 1
  • 16
  • 30
  • I have three referenced projects for this unit test. Two are .Net Framework 4.7.2, one is .Net Standard 2.0. They're all configured to build as "Any CPU", with "prefer 32 bit" unchecked. As I stated, this used to run and the only thing I did was refactor some methods used in the unit tests and then update the unit tests to allow it to build again. I also checked and made sure that all the referenced projects got included into the build directory as .dlls, per your first comment. I tried running as both 32 and 64 bit with no luck. I'll probably just remake the project at this rate. – Zulukas Feb 28 '19 at 16:40
2

I had a similar issue with a brand new test project in an existing solution - all of my other test projects compiled and tested correctly, but the new one repeatedly came up with the error:

No test matches the given testcase filter...

The answer came from this post VSTest: A testsettings file or a runsettings with a ForcedLegacyMode set to true is not supported with the MSTest V2 Adapter. No test is available which suggested switching off the testsettings file, which somehow had been selected on the new project.

As soon as I deselected the Test -> Test Settings -> c:...\Repos...testsettings option in Visual Studio the tests were runnable.

Liam
  • 5,033
  • 2
  • 30
  • 39
  • 1
    I don't see this option: Test -> Test Settings -> c:...\Repos...testsettings option.... There is no Test Settings – amr ras May 02 '21 at 01:25
0

In my case, the issue ended up being a mix of two different test engines. I inadvertently decorated my test methods with [TestMethod] (MSTest) when I was using NUnit. Once I changed my test methods to just [Test] and used the proper test runner, I was finally in business.

Steve
  • 506
  • 6
  • 16
0

I had a similar issue. In my case, the problem was the return type. The test method needed to use async but the return type was void instead of Task. Simple and small think that might eat a lot of time.

Roman Svitukha
  • 1,302
  • 1
  • 12
  • 22