Recently I wrote about the necessity in TDD of specifying both sides of a behavioral boundary, and its epsilon. This is important because we want a complete, detailed record of the critical business rules and other values in the system. But there is another reason that this is important. It has to do with the … Continue reading "Specifying Boundaries in TDD: Part 2"

Often a given behavior will change due to a certain condition: sometimes the system will behave one way, sometimes another. We call this kind of behavioral change a “boundary” and it should be specified as such in TDD. For example, let’s say there is a business rule that dictates how a passed-in value should be … Continue reading "Specifying Boundaries in TDD: Part 1"

TDD is different from QA in many respects. Part of this involves the tests we choose to write. A case in point is the specification of public constants. Example. When businesses buy assets, they can write-off (amortize) the value of those assets over time, as a taxation issue. The government will dictate how quickly a … Continue reading "Specifying Constants in TDD"

Because TDD is “test” driven development, people tend to think of TDD as “writing tests first.” In fact, TDD is not a testing activity per se. It is the creation of an executable specification prior to the creation of each system element. Unit tests are a very useful by-product of this process. Because of this … Continue reading "Commonly Missing Tests in TDD"

Design patterns in software came from the work of the Gang of Four in the mid-1990’s. Similarly, TDD was first promoted around the same time in history as part of eXtreme Programming. Some have suggested that these two points of view stand in opposition to each other, saying Design patterns are about up-front design, while … Continue reading "TDD and Design Patterns"

When a test precedes development, it essentially becomes the first “client” for the behavior being developed. This fact is helpful in several ways. First, the interfaces TDD drives into the system are always client-focused. They are not implementation-focused because at the moment they are created there is no implementation yet. In their seminal book on … Continue reading "Tests are Client Number 1"

When organizations adopt TDD as their development paradigm, early results can be quite good once the teams get over the initial learning curve. Code quality goes up, defect rate goes down, and the team gains confidence which allows them to be aggressive in pursuing business value. But there is a negative trend that can emerge … Continue reading "TDD “Good” Tests Part 3. There must be no other test that fails for this reason"

When a test fails for a reason other than intended, then upon investigating the cause of that failure the natural assumption will be that it is failing for the reason intended. Thus, the failure will mislead the team into investigating the wrong problem. Anything that wastes developer time is to be avoided resolutely. Developer time … Continue reading "TDD “Good” Tests Part 2. The test must never fail for any other reason"

TDD requires an expenditure of developer effort. All such effort is an investment, and thus should yield a return. TDD returns value in many ways, but here I will focus on one way in particular: Tests prove their worth when they fail. When a test fails, this is the point when we say “wow, we’re … Continue reading "TDD “Good” Tests Part 1. The test must reliably fail for the reason intended"

As consultants, we are often asked to review the work of others. One of the things we review is the quality of the design of some part of the system. Is it cohesive, decoupled, non-redundant, encapsulated, open-closed, and so forth? Often the developers understand and agree that these qualities are important, but they are not … Continue reading "“Good” Tests in TDD"