2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 15, 2017
- Write the Test First
As Misko Hevery, the author of AngularJS, says in his outstanding Google Tech Talk series “Clean Code Talks,” most developers assume they know how to write a good test but they don’t.
Knowing how to write a good test is paramount to being successful with TDD. Tests must be unique, expressive, and independent—easier said than done.
Doing TDD correctly is a discipline. It takes a deep understanding of a large body of knowledge as well as a lot of experience doing it. You can’t learn TDD from a 500-word blog post any more than you can learn brain surgery from one. It takes dedication, time, and practice.
I’m hooked on TDD but I guess I was predisposed to that since I’ve written automated test programs from the very start of my career as a developer and throughout the past three decades.
As I grow older my memory fades. This happens to all of us, although I didn’t believe it would happen to me when I was younger. Fortunately, wisdom replaces energy.
I lean on TDD to help me manage all those details I need to manage when I code. I rely on instant feedback from my builds to tell me if what I just did was a good thing or a bad thing. And with that kind of instant feedback, I make the connection between what I just did and how it affects my code.
Stimulus and response have to go together in order for an association to be made. If Pavlov rang the bell then fed his dogs an hour later they’d never make the connection. That’s why we don’t make the connection between the bugs we write when they’re found, weeks later, by QA.
But good unit tests help us make this connection by giving us immediate feedback whenever we make a change to the system. They also help us articulate the behavior we want to create and then validate that that behavior is working as expected.
Writing implementation independent tests by asserting against acceptance criteria or known behaviors gives us the freedom to change the implementation later without breaking our tests. Most developers weren’t taught how to do this, but writing good tests are central to success with TDD. Writing a test for every public method often drives us to write implementation-dependent tests, which can break when we refactor code.
Good tests are extremely valuable because they help you build out behaviors in ways that make sense and they support you in refactoring your code later. But in order for tests to have these amazing benefits and more they must be good tests. They must be unique, at the right level of abstraction, based on acceptance criteria, and be implementation independent.
I have discussed some of the major pitfalls to doing TDD in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, as well as on my blog. I also teach classes for professional software developers. Where you get experience doing TDD correctly you can see the benefits for yourself.
Previous Post: « Early Automation Experiences
Next Post: Domain Language »