Design Damage and Mocks

Two recent articles that are well worth reading. First, from David Hansson:

Test-induced design damage

And a rebuttal from Bob Martin

Test-Induced Design Damage?

I think both articles make some good points. On this issue I tend to agree more with David than Bob.

However, I think one of the main things both positions suffer from is a rather myopic view of testing. The focus is almost exclusively on unit testing. David asserts, I think convincingly, that you can damage your design by contorting it to be testable in the sense of old-school unit testing.

I think the problem is this focus on old-school unit testing. I also assert (without proof for the moment) that unit testing is a fiction. Any test code is always testing more than the strict object of the test. If nothing else you are also testing the run-time support of the programming language you are using. Yes, the test is geared toward a particular aspect of your design or implementation, but the notion of a test running in isolation is illusory.

If instead you look at a test as exercising a portion of a system, but with an eye toward proving out one aspect of it, the need to mock everything to death goes away. You spend your time building up an execution framework that doesn’t abstract away all the implementation details that, in the end, are just as important as whatever the object of your test is.

Building automated tests does not induce design damage. Mocking induces design damage.


About jeffkotula

Software engineer, musician, and so on...
This entry was posted in design, Software, Testing. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s