A contract represents a service agreement between two parties, the bounded provision of service by one party to the other. This metaphor also applies to how we can think about the relationship between unit tests and code. A contractual mindset encourages test names and partitioning based on clear propositions, backed up with executable examples.

Untruths about software testing are common. Managers, programmers, and other people on software projects don't always mean to deceive. Quite often, they fool themselves into believing what they want to believe. But sometimes they lie deliberately and even pressure testers to lie. And testers can also practice deceptions and self-deceptions of their own. In this column, Fiona Charles describes four categories of common deceptions and self-deceptions in testing and outlines what testers need to do to address them.

Whether or not a unit test is considered good is not simply about what it tests: It is also very much about "how" it tests. Is the test readable and maintainable? Does it define the expected behavior or merely assume it? To be sustainable, the style of a unit test is just as important as the style of any other code. Perhaps a little surprisingly, the most commonly favored test partitioning style does not meet these expectations.

Lisa Crispin explains in this article how CI has become an absolute necessity for any software development team in this day and age. For those who have yet to fully embrace CI, this article gives you some great reasons you should, along with some helpful resources to get you started.