Early Automation Experiences
Early Automation Experiences
Get the opinion of one Agile expert on why automated testing has come to shape the way he designs and develops his software.
Join the DZone community and get the full member experience.Join For Free
10 Road Signs to watch out for in your Agile journey. Download the whitepaper. Brought to you in partnership with Jile.
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.
Published at DZone with permission of David Bernstein , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.