TDD Pro-Tip: Wrap framework collection classes early and often. The Primitive Obsession smell is ubiquitous around collections, and not seeing and fixing it can greatly hamper productivity. In HollywoodSimulator, a common act of every Person is to spend time manipulating their little black book — the collection of the contacts they have. The first-pass way to represent this would be to use a framework collection class. In Java/Kotlin, that’s List<Person>. List<Person> is not a primitive, far from it, in Java […]

TDD Pro-Tip: Because the power of TDD is operational rather than artifactual, test-before provides several benefits over test-after. Sometimes folks propose the writing of tests after the code is written. The idea here is that the point of the game is to have the tests, and that it makes no difference whether we do them before we write the code or after. This idea is flawed: it centers TDD around the artifact — the made test — rather than the

TDD Pro-Tip: TDD depends heavily on a view that accepts and even values iteration. TDD is an I&I style of work: iteration and increment are both involved. Nearly everyone gets "increment": an increment is an improvement, an enhancement, a detectable step forward in value. Each increment is a pass over the code, during which we add to its function. TDD noobs take "increment", then, to mean "add a passing test". On the one hand, that’s great. On the other hand,

TDD Pro-Tip: The first step past beginner-TDD lies in grasping the difference between awkward and graceful collaborations, and learning the myriad contextualized patterns for moving from the former to the latter. Folks invest a little in TDD, maybe cuz they’re excited, maybe cuz they’re ordered. They read a little. They try an exercise or two. They learn a little about their xUnit options. Maybe they boldly even use TDD to write a method or a class in their day job.

TDD Pro-Tip: Build cells — logic nucleus on the inside, environment inputs & outputs on the outside, and a semi-permeable cell wall between the two. The metaphor i’m proposing here is really about the nature of borders in code. Prior to TDD, my grasp of this topic was driven largely by the great theory of object-orientation that began to emerge back in the ’80s and came to dominate the modern s/w landscape. As with so many aspects of the programming