Think of the smallest unit test you can run for your software. No, smaller. Developing that test may need to be the first step to successful development.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
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 first.
Then you’ll be flying with your eyes wide open.
Published at DZone with permission of David Bernstein , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.