Motley says: "Contracts are for baseball players and cell phones"

Summary

Motley: Contracts don't apply to software - leave them for baseball players and cell phone providers

Maven: Contracts (preconditions, postconditions, invariants) help drive your unit tests

______________________________

[Context:  Motley is all excited as he has started to measure code coverage on his tests]

Maven: Hey Mot. Remember that conversation a while back that you said you were looking forward to as much as a cat looks forward to being neutered? I was looking over some of your unit tests and I think it's time we had it.

Motley: Yippee-ki-yay. You may know what the next part of that phrase is if you are a movie buff.

Maven: Ouch! I assume you're joking <laugh>. Anyway, about those tests. Your code coverage numbers are pretty good.

Motley: Excellent! Glad to hear something positive come out of your mouth!

Maven: Absolutely. I think you are making some great progress and the other devs are really looking up to you as a leader. I do, however, have an idea to make your tests better. Bear with me for a second. Although the coverage numbers are good, you're still missing some cases as per our last conversation.

Motley: Ok, you buttered me up a bit, so I assume you want something. I'll hear you out.

Maven: A good way to ensure you thoroughly test a method is to think about the contract of a method.

Motley: Contracts are for baseball players and cell phone customers and providers. I don't see how this is relevant.

Maven: If you think about your cell phone contract, your cell provider has certain expectations of you, and you have certain expectations of them. In the meantime, they may do some things that violate those expectations but they keep it invisible so that your expectations remain consistent. The same thing works for software. When you write a method, think about the preconditions of the method - what must be true before the method is called, the postconditions of the method - what must be true when the method is complete, and class invariants - what must be true before and after a method, but not necessarily during the execution of the method.

Motley: I think better with examples, dude.

Maven: Sure. An example of a precondition might be that an integer input parameter must fall within a certain range. An example of a postcondition is that the returned object cannot be null. An example of a class invariant is that the state of the class must be some value before and after the method, but could change during the method, like before a call to a private method, and restored after that call.

Motley: Wow. That would be a lot of extra work to think about that for every method!

Maven: It is extra work, but think about the benefits you gain when writing tests against a public method. Contracts help you frame your tests and make sure you have all boundary conditions/corner cases covered. Contracts also enhance the documentation around a method making it easier for someone to understand its usage.

Motley: I can see some value in thinking this way, but going through all this extra work in specifying a contract just to think through my tests seems like lots of work for minimal gain.

Maven: Well, you'd have to thoroughly test the method anyway. This is just a different way to think about it. Let's cover how tools can actually help us out with validating contracts …

______________________________

Maven's Pointer: Using contracts to design software is often referred to as Design by Contract. Thinking about your methods in terms of contracts helps drive quality of those methods. These contracts and associated unit tests actually become the formal specification of your software. Anyone wanting to know how the software is to be used (like the test team) can examine a contract and even without full documentation, can get an accurate picture of how the method is to be used.

Maven's Resources:  Design by Contract on Wikipedia, An interview with Bertrand Meyer, who is credited with inventing the technique