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
- December 20, 2017
- Write the Test First
The way most software is developed—designing entire programs on paper and then typing them into a computer in their entirety before they run—is like flying blind.
Software is virtual. We can’t see it or touch it. The only feedback we get is when we compile and run our program. But on a Waterfall project that can take weeks or even months to happen.
If I were building a compression library using Waterfall, for example, I’d design the platform, code the services, and it might take several months before I could start running the program through a debugger. All of that time I’d be flying blind.
Without the feedback of my compiler, I won’t even know if I’m making syntax errors. I just have the fallible human process of checking by hand until I get enough of the program written that I can run it and see some results.
This is why I write software test first.
I start with the smallest test I can think of so I have something up and running right away. I then add the smallest bits of functionality I can think of as I build out the system, all the while compiling and running my tests as I go.
Doing TDD means that I always have a buildable version of the system as it’s being built, even on day one. My system may not yet be able to do anything meaningful on day one, but it’s buildable, and as the smallest bits of functionality get added, all of the previous tests get run to ensure there are no subtle interactions between components and keep things functionality independent.
When I do TDD I can see into my system and always know what state it’s in: green or red. Green bar means everything’s great. Red bar no so much. We never let our system stay red for very long and since we make small, incremental changes to the system, we know it’s usually that last change we made that caused the system to break so we can easily back out the change with version control.
Our tools are only as good as we let them be. A shortwave radio can be used to call for help but only if you turn it on. In order for all software tools to work, and this includes compilers; lint checkers; linkers; unit, functional, integration, and system tests, you have to have a buildable version of your code so you can exercise it the way it will be used in the program. The fast and easy way to do this is to build a test harness. And if you’re going to have unit tests for your code then you may as well write it test first.
Then you’ll be flying with your eyes wide open.
Previous Post: « Change Your Mind, Again
Next Post: Don’t Be Scared to Touch Legacy Code »