Software Quality

January 18, 2010

A metaphor for the synergy between automated testing and contract programming

Filed under: Practices — David Allen @ 4:50 pm

I read a great blog article the other day by Matthew Podwysocki  “.Net Code Contracts and TDD Are Complementary”.      I also wrote an article on the subject a few weeks ago Those articles describe different roles these techniques play in the development process and how they both contribute to better software quality.  I won’t repeat the logical arguments made there. But I had an idea for a metaphor to help make these ideas memorable, communicating the synergy achieved by combining both of these techniques. 

Computer software is like a person looking for a job. The job applicant has a resume which describes the goals, experience, and skills of the applicant.   Here is an example of a resume 

David Allen

     Looking for a job that involves physical activity and some interaction with computers

     Warehouse Handler
           Carried boxes (5-15 lbs) to the loading dock
           Completed inventory on a weekly basis
     Can type 20 words a minute
     Can lift boxes of 100 pounds safely
     Certified to operate a Clarke model FL20 forklift

 Computer software is written to meet goals that are expressed in high-level tests and comments.

In software, automated unit tests demonstrate what the code can do by illustrating what it has done (what has been tested). With code, as with job applicants, past results are indicative of future performance.

In software, code contracts precisely define what the code is capable of doing.  Just as a knowledge of and applicants skills allow the employer to envision new and different ways they can serve the business, likewise, code contracts allow other programmers to envision new and different ways that the code could be combined to solve different problems.

However, one of the differences between software and a resume is the fact that we often highlight our strengths in resumes, without indicating our weaknesses or limitations. We usually wait for the interviewer to uncover our weaknesses and limitations. At least this is consistent with job hunting in American culture.  In contrast, with software, we write code contracts to be fully revealing of the strengths and weaknesses of the code. As a job seeker, I may be eager to get a job offer, and sensitive about how I portray myself; I do have an ego after all.  But a class has no need to buy food or clothing. And it has no insecurities about it capabilities. Nor does it write its own resume. I as a programmer write the code. I want to be brutally candid about what it can do and what it cannot do. And code contracts are an excellent way to express the possibilities and limitations of a class and its features.

In summary, I believe it automated testing and code contracts are complementary practices, and each contributes value towards the creation of reliable software.  Automated unit tests demonstrate what the code has done and how it can be used similarly in the future. Automated integration and story tests give a better picture of the higher-level goals. And code contracts describe the inherent qualities of the code, including both what it can do and what it cannot do. The information offered by code contracts allows designers to make changes in the code more effectively because they have a deeper understanding of what the code is and is not intended to do.

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment: 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

Blog at

%d bloggers like this: