NSubstitute test works by itself, but throws Unexpected Matcher Argument in a suite

Question

I have a unit test where I use .Returns() to return some sample data:

    [TestMethod]
    public void TestRetrieveElementsInVersion()
    {
        IRetrieveElementSequence component = Substitute.For<IRetrieveElementSequence>();
        List<UnconstructedElement> list = new List<UnconstructedElement>
        {
            new UnconstructedElement{Version = "1"},
            new UnconstructedElement{Version = "2"}
        };
        component.RetrieveElements().Returns(list); // exception reported here
        const string target = "1";
        IRetrieveElementSequence service = new RetrieveElementsInAVersion(component, target);
        IList<UnconstructedElement> result = service.RetrieveElements();
        bool check = result.All(e => e.Version == target);
        Assert.IsTrue(check);
    }

This code passes in Visual Studio using the ReSharper runner, when the test is run alone. It fails when it runs as part of a list, like when I Run All Tests from Solution.

NSubstitute.Exceptions.UnexpectedArgumentMatcherException: Argument matchers (Arg.Is, Arg.Any) should only be used in place of member arguments. Do not use in a Returns() statement or anywhere else outside of a member call.

I don't see where I am even using Arg.Any or Arg.Is. What am I doing that makes NSubstitute complain? This happens when I use the .Returns() to return lists of non-native objects.

Answer 1

This is most like due to a previous test using an argument matcher against a non-virtual method, or in a Returns statement.

Unfortunately this can be quite tricky to debug. First step is to see if the problem occurs when you run all the test in this fixture. If so, check all uses of Arg.Is|Any in that fixture, starting with the one that runs immediately before the test that fails (if your test framework uses a predictable test order, otherwise you'll need to look at test logs to see what tests proceed the failing one).

If it does not occur with that fixture you'll need to look through the fixtures that run beforehand to see where the left over arg matcher is coming from. It is most likely somewhere near the failing test.