NSubstitute AmbiguousArgumentsException: Cannot determine argument specifications to use.

I had a few tests that failed with error  

NSubstitute.Exceptions.AmbiguousArgumentsException: Cannot determine argument specifications to use. Please use specifications for all arguments of the same type.
They are similar to http://stackoverflow.com/questions/26805420/nsubstitute-testfixture-1-causes-ambiguousargumentsexception-in-testfixture-2.

I installed the latest version of NSubstitute, but it didn’t help.

As it was advised by David, the errors were caused by calls to non-substituted methods with Args.* parameters. Arg.Any were passed to actual code methods, that where called without Returns or Received parameters.



The errors did not happened  when Microsoft tests were running under  MSTest, but started when I switched to VSTest.Console.
To scan my test library I used search with regular expression to find rows with Arg.Any but not Arg.Any following by Returns or preceding by Received


It’s not bullet proof filter( e.g it doesn’t exclude multi line statements), but it helped to reduce number of calls to check.

#nsubstitute, #tests, #vstest

Replace MSTest to VSTest to support Fakes

I’ve created a unit test using MS Fakes Framework. When I tried to run it from the build script, I’ve got an error:
Test method DateTimeHelperTests.ConvertServerTimeToTimeZoneTimeTest threw exception:
Microsoft.QualityTools.Testing.Fakes.UnitTestIsolation.UnitTestIsolationException: Failed to resolve profiler path from COR_PROFILER_PATH and COR_PROFILER environment variables.
The answer of
http://stackoverflow.com/questions/26743342/running-a-test-using-shims-on-a-visual-studio-2013-test-agent told that instead of “using mstest.exe  I should have been using vstest.console.exe.”
There are a couple articles that explain the differences between MSTest and VSTest.console.exe.
I’ve created below table to describe parameters that should be changed if you move from MSTest to VSTest.
C:\Program Files (x86)\Microsoft Visual Studio 14\Common7\IDE\MSTest.exe
C:\Program Files (x86)\Microsoft Visual Studio 14\Common7\IDE\CommonExtensions\Microsoft\ TestWindow\VSTest.Console.exe
Full Path for typical installation
mstest /testcontainer:tests.dll
Vstest.console.exe myTestFile.dll myOtherTestFile.dll
Pass test.dll
TestResults\UserName_MachineName 2016-04-07 18_12_02.trx
/Settings:[file name] e.g.
mstest /testcontainer: “C:\TestProject2\myTestFile.dll” /testsettings:Local.TestSettings /category:!Broken /resultsfile:testResults.trx
vstest.console.exe  “C:\TestProject2\myTestFile.dll /Settings:Local.RunSettings /TestCaseFilter:”TestCategory=!Broken” /Logger:trx
Full example
<!– MSTest adapter –>
<MapInconclusiveToFailed>True </MapInconclusiveToFailed>
<DeleteDeploymentDirectoryAfterTestRunIsComplete> False </DeleteDeploymentDirectoryAfterTestRunIsComplete>
RunSettings for vstest.console adapter
/test:[test name]
to run multiple tests, use the /test option multiple times.
TestClass matches if the name Contains pattern
/Tests:[test name]
To provide multiple values, separate them by commas. Example: /Tests:TestMethod1,testMethod2
Classes and Methods matches if the name contains pattern
Also VSTest is running all tests in a single thread, so there is no proper isolation between tests and settings in one tests may effect subsequent tests.
I had to fix a few tests before the whole test project passed under VSTest.

#fakes, #unit-tests, #vstest