Moq - Tests run ok when executed independently, but fail when executed in a row

We are using Moq to perform some unit tests, and there's some strange behaviour, perhaps it's some configuration issue that i'm missing.

basically, i have 2 tests (which call a windows workflow, which calls custom activities that call a method using Invoke. i don't know if this helps but i want to give as much info as i can). The tests run OK when executed alone, but if I execute them in a same run, the first one passes and the second fails (doesn't matter if i change the order of them, the 2nd one always fails)

The mock is recreated every time, loaded using Unity. ex :

MockProcessConfigurator = MockFactory.Create<IProcessConfigurator>();
 MockProcessConfigurator.Setup(x => x.MyMethod(It.IsAny<Order>()));
[...]
InversionOfControl.Instance.Register<IProcessConfigurator>(MockProcessConfigurator .Object)

The invoked call (WF custom activity) is

var invoker = new WorkflowInvoker(new MyWorkflow());
invoker.Invoke(inputParameter)开发者_如何学运维;

The call (Invoked call) is

MyModuleService.ProcessConfigurator.MyMethod(inputOrder);

when debugging, i see that the ProcessConfigurator is always mocked.

The call that fails in the test is something as simple as this :

MockEnvironment.MockProcessConfigurator.Verify(x => x.MyMethod(It.IsAny<Order>()), Times.Exactly(1));

When debugging, the method is actually called everytime, so i suspect that there's something worng with the mock instance. I'm a bit lost here, because things seem to be implemented correctly, but for some reason when they're run one after the other, there's a problem

---

This type of error commonly occurs when the two tests share something.

For example, you set up your mock with an expectation that a method will be called 1 time in your test setup, and then two tests each call that method 1 time - your expectation will fail because it has now been called 2 times.

This suggests that you should be moving the set up of expectations into each test.

---

A generic troubleshooting for this type of problem is to try to isolate the dependency between the two test.

1. Move any setup-code to inside the tests.
2. Move any tear-down code to inside the tests.
3. Move any field initializers to inside the tests. (Those are only run once per fixture!)

This should make both your test pass when run together. When you got the green-lights, you can start moving out duplicated stuff again to initializers/setup one piece at the time, running the tests after each change you make.

You should be able to learn what is causing this coupling between the tests. Good luck!

---

Thought I'd add an additional situation and solution I just came across:

If you are running tests from two separate projects at the same time and each project is using a different version of Moq, this same problem can happen.

For me, I had TestProjectA using Moq 4.2.14 and TestProjectB using Moq 4.2.15 on accident (courtesy of Nuget). When running a test from A and a test from B simultaneously, the first test succeeded and the second silently failed.

Adjusting both projects to use the same version solved the issue.

---

To expand on the answer Sohnee gave, I would check my setup/teardown methods to make sure you're tidying everything up properly. I've had similar issues when running tests in bulk and not having tidied up my mock objects.

---

I don't know if this is relevant, but MockFactory.Create seems odd. I normally create mocks as follows:

var mockProcessConfigurator = new Mock<IProcessConfigurator>();

When using a MockFactory (which I never have needed), you would normally create an instance of it. From the moq QuickStart:

var factory = new MockFactory(MockBehavior.Strict) { DefaultValue = DefaultValue.Mock };

Calling a static method on MockFactory seems to defeat the purpose. If you have a nonstandard naming convention where MockFactory is actually a variable of type MockFactory, that's probably not your issue (but will be a constant source of confusion). If MockFactory is a property of your test class, insure that it is recreated on SetUp.

If possible I would eliminate the factory, as it is a potential source of shared state.

EDIT: As an aside, WorkflowInvoker.Invoke takes an Activity as a parameter. Rather than creating an entire workflow to test a custom activity, you can just pass an instance of the custom activity. If that's what you want to test, it keeps your unit test more focused.