Writing unit tests is not something we are very good at on our team. Some of us truly believe and practice the principles of TDD to the extent possible and, others simply “don’t have time”.
We did impress upon our co-workers the importance of practicing the art of writing unit tests. Off they went to write their first set of tests. D came back with questions and our conversation went something like this
D: I wrote this unit test to test this method on the data repository class that calls this other thing. So what is my unit test doing?
I: It is testing the method on the repository class.
D: So AM I good here.
I: Well here is the thing. Your unit test is testing the method foo on the repository class. But foo is calling bar on the other class. When the test fails we don’t really know if the failure is in foo or bar.
D: Ah, I see. So what good is this test?
I: The test is good. Unfortunately we have to refactor the class so we can inject into the repository this other “provider” of bar.
D: Why would I do that?
I: That will allow us to use a mock object to mock up the provider, add some “known” expectations and exclusively test foo and only foo. Any test failure tells us that something is wrong with foo.
D: Ah Ha. The unit test exposed a flaw in our design.
I: B I N G O!! Another light goes on.