So, I’m reasonably new to both unit testing and mocking in C# and .NET; I’m using xUnit.net and Rhino Mocks respectively. I’m a convert, and I’m focussing on writing behaviour specifications, I guess, instead of being purely TDD. Bah, semantics; I want an automated safety net to work above, essentially.
A thought struck me though. I get programming against interfaces, and the benefits as far as breaking apart dependencies goes there. Sold. However, in my behaviour verification suite (aka unit tests 😉 ), I’m asserting behaviour one interface at a time. As in, one implementation of an interface at a time, with all of its dependencies mocked out and expectations set up.
The approach seems to be that if we verify that a class behaves as it should against its collaborating dependencies, and in turn relies on each of those collaborating dependencies to have signed that same quality contract, we’re golden. Seems reasonable enough.
Back to the thought, though. Is there any value in semi-integration tests, where a test-fixture is asserting against a unit of concrete implementations that are wired together, and we’re testing its internal behaviour against mocked dependencies? I just re-read that and I think I could probably have worded it better. Obviously, there’s going to be a certain amount of ‘well, if it adds value for you, keep doing it’, I suppose – but has anyone else thought about doing that, and reaped benefits from it outweighing the costs?
Your question has been debated for years and can also be rephrased as ‘what is a unit’?
There is no law of unit testing that says you need to test each class in isolation. However, to be maintainable, your really want tests to only have to change when the behavior they test changes. Looked at it this way it is often reasonable to use concrete versions of close collaborators and fakes for more distant ones.
The one place I absolutely use fakes of one kind or another is to follow Michael Feather’s Rules of Unit Testing.