2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – 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 8, 2017
- Integrate Continuously
We didn’t do a lot of automated testing as an industry back in the late 1980s, but I did.
I was working for IBM on one of the first hypertext implementations, which later became HTML. Our authoring system created very complex data structures that required us to do extensive testing to validate they were correct.
I’m a lazy guy and the thought of running a series of manual tests—over and over, each time we made a change—to verify that the data structures our authoring system created were correct, was unappealing to me. So I wrote an automated test runner that was data driven. In many ways, my test runner was much more complex than the code it was testing. It took a long time to write and debug, but once I got it working, life was great. I could generate a new testing scenario in just a few minutes so I could test our data structures very deeply. And I found some obscure bugs I probably never would have found if I was only doing manual testing.
This was one of my early experiences automating testing, circa 1988. Three years earlier I wrote a data-driven report writer for the banking application I built. My test runners had a similar design.
Today, I wouldn’t think about writing code without building it test first. A suite of good unit tests is more than a safety net for catching bugs, they inform my designs and help me write code that’s more maintainable. Writing tests before writing implementation drives me to write functionally independent code that’s independently verifiable and testable. They keep me focused on implementing a single intention at a time, and they help separate tasks in ways we naturally think.
But unfortunately, when I visit clients or go to conferences and talk to other people who are doing TDD, I don’t always find the same enthusiasm for the practice. Many developers I’ve met have tried TDD and abandoned it. They found it impractical, that it requires too much overhead to maintain tests.
This is not a fault of TDD but rather a fault of the way people apply TDD. We have to know how to wield TDD correctly. When we don’t it goes from being an asset to being a liability.
Unfortunately, there aren’t many good books on doing TDD well. Kent Beck’s book, Test-Driven Development by Example is a great book but there needs to be many more great books on TDD.
Doing TDD well isn’t something you can learn from a blog post or in a few minutes. It’s a discipline that requires a great deal of study and practice. The path to doing TDD is fraught with misunderstandings and poor practices. People simply don’t understand what it is and therefore they use it improperly.
I’ve done my best to write about how to do TDD and other development practices, as well as try to explain some of the pitfalls. My book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, discusses the motivation, value, and purpose of TDD as well as several other practices. I’ve also written hundreds of posts on this blog about effective ways to build software, but there’s no substitute for doing it in an environment that supports you in building good habits, like my CSDE and ADET classes do.
Contact me if you’d like to learn more.
Previous Post: « Changeability
Next Post: Writing Good Tests »