TDD

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

TDD Pro-Tip: Prevent complex test data from spiraling out of control by going to builder & custom comparator early on. The push-to-small, coupled with SOLID, coupled with things like third normal form, all lead us to a place of wanting to compose domain objects into potentially very rich dependency graphs. A card in a address-tracking subsystem sounds at first blush like a class with about 5 simple strings in it, and we certainly start there when we first approach it.