The answer is probably very obvious most of the time. The first test did one of the following
- changed the state of objects that were used by other tests
- the first test consumed expectations on shared mocked objects
- mock controls were set but not reset at the end of the first test
I ran into this one today. I had all tests passing when running them independently but only the first one passing when running all tests in the file. Having made sure I was resetting the mock controls and the expectations were set correctly, I knew it had to be the first one where the status of objects were changed.
The problem was that my object under test was a singleton class. The first test created the object under test based on mocked arguments in its constructor and the test passed.
However, when the second test was run, despite the fact that I had reset the IMocksControl object in my test, the expectation in my second test were not being met. You can probably already see what is happening here. The object under test is the same instance (as in the first test - given that its a singleton) and the mocked objects that I passed in during the first test persisted. So when the second test 'expected' things to happen, the expectations were never fulfilled because they were already consumed by the first test. Regardless of whether the object under test was a member variable or a local variable for each test, it did not make any difference.
I fixed the issue by cautiously creating setters with default access so that the second test could supply new set of mocked objects to the object under test. This takes me back to the sameissue that I have never felt comfortable with - exposing for test purpose - but have done it anyway in multiple instances.
- changed the state of objects that were used by other tests
- the first test consumed expectations on shared mocked objects
- mock controls were set but not reset at the end of the first test
I ran into this one today. I had all tests passing when running them independently but only the first one passing when running all tests in the file. Having made sure I was resetting the mock controls and the expectations were set correctly, I knew it had to be the first one where the status of objects were changed.
The problem was that my object under test was a singleton class. The first test created the object under test based on mocked arguments in its constructor and the test passed.
However, when the second test was run, despite the fact that I had reset the IMocksControl object in my test, the expectation in my second test were not being met. You can probably already see what is happening here. The object under test is the same instance (as in the first test - given that its a singleton) and the mocked objects that I passed in during the first test persisted. So when the second test 'expected' things to happen, the expectations were never fulfilled because they were already consumed by the first test. Regardless of whether the object under test was a member variable or a local variable for each test, it did not make any difference.
I fixed the issue by cautiously creating setters with default access so that the second test could supply new set of mocked objects to the object under test. This takes me back to the sameissue that I have never felt comfortable with - exposing for test purpose - but have done it anyway in multiple instances.
No comments:
Post a Comment