Test Driven Architecture
In the latest issue of the Architecture journal, Mario Cardinal wrote an article called Test Driven Infrastructures in which he discussed the idea of test driven architecture. He said that it is a good way of documenting the code, avoiding regression bugs and making sure that the developers are sticking to the requirements and the design.
I think of test driven development to be something that makes sure that you reach the end goal without checking the way you get there. See the following example situation:
 I am designing an application that gets some data from the database and display them for the user. I choose to use N-Tier architecture with 3 tiers, one for the database, one for the data access layer and one for displaying the data to the user. If I put a unit test for the use case of the user requesting the data to be retrieved and displayed, how can I test that the developer is sticking to the 3-Tier design that I have made? How can I make sure that he is not writing code in the presentation layer that connects directly to the database?
This is something that was not mentioned by Mario Cardinal in his article but was mentioned by Peter Provost in his short video about test driven design. He said that test driven design is used to test methods and classes, not the higher level architecture, and I think that the same principle of “testing the goal not the way to the goal” applies even to small methods and classes. If I put a design that included a method that takes an array and sorts it, and I said that I need the sorting to be done using x algorithm (for the sake of performance or memory usage or any other reason), how can I put a unit test that makes sure that the developer implemented it in the same algorithm that I explained to him?
Another difficulty in test driven development is creating the tests by someone who is not a tester (the software architect). Design, development and testing are three different jobs that require different skills. A good developer or designer is not a good tester necessarily. See this blog for a discussion for the idea.
Of course there are benefits for test driven development or design, such as avoiding regression bugs and a good way for documenting the design (when combined with other design document and diagrams, not alone).
No silver bullet, the old immortal rule for software development. If you want to use Test driven development for its benefits, you should make sure that your unit tests are not the only tests you are using. Use also other testing techniques (for example peer review) to cover the holes left by your unit tests. Â
Comments
Leave a Reply