Pro-Tip

TDD Pro-Tip: What we TDD most rigorously and faithfully is our branching logic. This is the insight one needs to start gaining TDD’s massive productivity benefit. All three terms are important, "our", "branching", and "logic", so let’s take them one at a time. Remember as we forge in to this: there is no free lunch, but if there were a free lunch, writing a test ain’t it. Every test we write costs something and benefits something. We need that benefit […]

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

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.

TDD Pro-Tip: TDD and refactoring are permanently intertwined activities, neither of which can be grasped all at once, so start learning how to write tests at the same time you’re learning how to change code w/o adding bugs to it. Some activities are what I think of as "life games". The better you get at it, the more there is to learn. I call them games, cuz my first two noticed experiences of this were in the games of pool