Programmers routinely give up on TDD when they try to do it in their toughest, meanest, most-valuable legacy code. I understand their impulse, but I think they’re setting themselves up for failure and ultimately missing out.
Which Kinds of Tests Should I Write?
Programmers routinely ask me for advice on which kinds of tests they ought to write: unit vs. functional, fast vs. slow, big vs. small. They keep saying “integration test” when they mean “integrated test”. We have made this confusing, so I’d like to take one step towards clarifying it.
The Saff Squeeze
Debug with automated tests: it’s systematic, it leaves a record of what we’ve learned, and it’s boring in the best possible ways.
Polynomial Kata in 46 Commits
An example of test-first programming, focusing on adding behavior incrementally and removing duplication.
Modularity and Performance
Are you worried that all these little classes and interfaces are going to destroy your system’s performance? Maybe. More often, however, the bottlenecks are caused by bigger classes and fewer interfaces causing duplication in the design.
Zero to nodejs on Linux
A concise guide for going from nothing to a working nodejs environment on Linux environments.
Reading stdin and The Kotlin DSL for Gradle
How does one accept user input from stdin in a Java application when running it with gradle run when using the Kotlin build DSL? Here’s how!
Breaking Through That First TDD Block
Some programmers try TDD and feel blocked right away. “How do I write a test for code that doesn’t yet exist?!” I remember how it felt and what happened when I tried anyway.
Edit, Then Execute
If you want the full power of your trusted text editor to compose and edit long shell commands, then you can have it!
How I Wish I Had Some Unit Tests! An Example
The integrated tests scam goes beyond “merely” making tests slow and brittle. Sometimes they render impossible an otherwise straightforward test.
How to Write Tests For Framework Extensions?
Programmers get into trouble when they try to use one set of tests to check their code and someone else’s framework. Clarifying the intention of the tests and isolating these two kinds of behavior from each other tends to lead to better results overall.
Abstract Test Cases, 20 Years Later
Revised one of my earliest contributions to the evolutionary design community: abstract test cases and their evolution into contract tests