TDD is cool, but..
Recently I gave a presentation to my company HQ in Maynard, Massachusetts, USA where I tried to present the importance and benefits of Test Driven Development.
The purpose of presentation was to present MVP design pattern as a way that we can decouple our presentation logic from the UI elements. Doing this would enable unit testing of the UI business logic located in the presenter. I had a rough time because the whole presentation was only an hour and a half. I spent a lot of time explaining our current business problems that MVP and test driven development can solve. Anyhow, after half an hour of talking really fast I somehow gave a general overview of MVP and, judging by the people’s faces, I think I sold them on the usefulness of MVP in WebUI.
But some problems emerged in second part of the session, when I had only 20 minutes to present the concept of dynamic mocking as a way of writing tests for the presenter before implementing the presenter. Explaining what is mocking and how it works, the benefits of dynamic mocking, and some general overview of what Rhino mocks are took 20 minutes, so when I started to write first test tp describe presenter initialization behavior, time ran out.
In the last five minutes of wrapping up I heard a couple of typical questions which I hear all the time when I’m trying to present the usefulness of TDD to someone.
Some of the questions are:
- It is cool, but we would spent a lot of time writing test scripts.
- It is cool, but we are not using real objects for testing, so test results with real objects might be different.
- It is cool, but it requires that developer has intimate knowledge about the tested code at the moment when the tests are been written.
- It is cool, but we have already a functional requirement document (FRD) which describes the same things, so writing test would only double our efforts.
My short replies:
1. True, but only if you are not unit testing your code at all. If you are writing unit tests after the code is written, I believe there is an obvious additional benefit of using the tests (during development) as a guideline. Another advantage is that these behavioral tests may be the best type of functional documentation. They quickly and precisely give other developers an overview of the purpose and usage of the component.
2. False. When you are testing the presenter, you are writing tests for the presenter class itself, not the presenter mock, so nothing would change “after”. You are mocking view and data source only, and they are not the test subjects.
3. False. Default recording mode of the rhino mocks is Unordered, which means: “I expect that public presenter method call would make something happen inside presenter which would produce some effect on the view interface but I don’t know what would happen, when it would happen, and in which order.” That sounds pretty “black boxed” to me.
4. True. At least, if you don’t care about the time and money spent on the incorrect code implementation cause by misinterpreting the FRD. By relying on word documents, there’s no way to guarantee that requirements are fulfilled. The only way to verify that the requirements are satisfied is testing during QA phase when all the code is been already done. By this point, any misunderstood FRD requirement will cause (sometimes significant) code changes, which lead to another QA phase, etc. In my opinion, an FRD word document is not a technical document. It is a business document which belong in to the Land Of Suits. The Technical FRD is the set of behavioral unit tests translated from Word FRD document. Developers shouldn’t care about word documents. These functional tests also allow for transparent progress tracking. If 10 of the 30 tests pass, that means the task is 33% complete.
My next blog will be about the second part of my presentation: Rhino mocks- usage, benefits, and TDD.
Until then you can take a peek at the code sample I used in my presentation:
(You’ll need VS2005, NUnit and Rhino Mock installed on your computer to run the example.)