Brian Merick states, "The desire to have tests that run fast and provide a good idea of your status leads to positive design changes that make the program more maintainable and more flexible," in a RationalEdge interview by Sam Guckenheimer.
So to make testing easier, I changed my plan for the structure of the program from the obvious -- GUI and business logic all glommed together into one application, one executable process -- to a Web Services type of structure. Then I start thinking, "Maybe I'll put in an HTML front end so I can record my time from any place I have a Web browser. Or, since this is something like SOAP, which lets you talk from anywhere on the network, I could write a GUI client that talks to this central server." And all of a sudden, I have given this simple, dumb, little app running on a Macintosh the ability to be much more flexible. And I don't know if I will ever do any of this stuff, but I have the ability to do it. And this is quite similar to what programmers experience with test-first design. The desire to have tests that run fast and provide a good idea of your status leads to positive design changes that make the program more maintainable and more flexible.
People typically say you need a clean interface between the business logic and the GUI, but here I have a GUI that is physically separated from the business logic by a network -- which makes it much more difficult to break modularity. Plus, I need to keep the tests running -- and that discourages me from cheating and forgetting the motivation for the separation.
Previous Topic
