One of the benefits to interaction-based unit testing is how much easier it is to truly test only the class under test and not its underlying implementation. You simply compose the class with all of the “worker” objects it needs to get its job done, and then mock them out in your test. Set your expectations of these mocked out objects and there you go; you are only testing your class’s implementation.
There is a complication in several of today’s most popular programming languages, however. The most popular mock generating libraries in C# and Java only provide full functionality for interfaces. No interface, no mock. No problem you say “As I am a good developer, I always design by contract and so all of my classes provide an interface.” Good for you, but what about File(C# and Java)? Or Point(.Net graphics)? Or any class from a less-enlightened third party library?
The answer is to wrap all such classes with an interface and a simple redirecting implementation, and then use that interface in your code instead of the real thing. Now you have the interface you need to mock out the class’s functionality. Consider replacing the code segment below:
With this instead:
Of course, you also must supply the interface and the implementation of the reflection class:
While this does represent a little extra work, it provides the very tangible benefit of making the MyBetterClass class much easier to test. Try this little tip while exploring interaction based testing and let me know what you think.
Interaction-based testing links:
Mocks Aren’t Stubs by Martin Fowler
State vs Interaction based Testing by Nat Pryce
[…] An Atomic Spin blog entry about interaction-based testingShow: ARCast with Ron Jacobs […]
To use this example you would need something like this right?
MyBetterClass o = new MyBetterClass(new FileFromInterface());
o.Remove(“thisfile.txt”);
if so it seems pretty complex for the benefit (instantiating 2 objects); is it that advantegeous?
I definitely see the point to this. the only problem with it is, the Exists method in the interface. Use File.Exist in the implementation of the interface. MyBetterClass only needs to call m_File.Delete. The interface implementation will check if it exists or not.
Zman:
Yes, you would create the MyBetterClass with an instance of the FilefromInterface class. As far as the benefits to cost question I guess it is a matter of values. As I said in the article, there is a little bit of coding needed, but I place the value of ease-of-testing much higher than the inconvenience of a small amount of extra typing.
Joseph:
When I wrap classes in this way, I try to keep the wrapper as close to the original (and therefore as simple) as possible. If I decide that additional functionality is needed (like in your example) then I would make an additional interface (and class) that defines the desired behavior and fully test that class.
It is important to remember that the reason for creating this wrapper is to convert a class that does not lend itself to easy unit testing into one that does. Any functionality beyond this should be fully tested along with the rest of the system.
[…] An Atomic Spin blog entry about interaction-based testingShow: ARCast with Ron JacobsTags: Architecture […]
It occurs to me that there should be an automated tool for producing these wrapper interfaces and classes…