Disclaimer: I have yet to figure out how to write unit and integration tests for articles and blog posts. Ideally, all of my punctuation problems would be hashed out in unit tests; while integration tests would make sure that it all flows together. So I apologize in advance for any bugs in my blog post.
TDD A personal Journey
My first experience with test driven development was in a college course: Software Testing and Maintenance. I have to admit I was not excited about this class at first. But I accepted that the skills were valuable because I would end up maintaining a code base.
I still remember our first TDD assignment. We had to recreate Uncle Bob’s bowling application. If there’s one thing you need to know about Uncle Bob, it’s that he TDD’s like a boss. For the assignment, my team and I wrote all the code up front and then tried to write the tests… WHICH TOOK 3 TIMES LONGER THAN DEVELOPING THE ACTUAL CODE. After that, just the thought of test driven development put the nastiest taste in my mouth.
Why would someone waste time writing tests when they could prove that it worked with manual testing in 5 minutes?
Looking back, I realize we made that assignment much harder than it needed to be because we wrote our tests last; if we had wrote the tests first, our code would have been testable and easy to refactor. Since we wrote bad code first, it was hard to write tests, yet alone good tests, that passed…
Later that semester, I interned at a local start-up developing what we thought at the time was the future of fantasy baseball. During development, my team had some downtime and the lead developer suggested that I spend my time writing test cases for the application. I cringed a little inside, but accepted the challenge all the same. I slowly figured out how to test the application over the weekend, and, on Monday, I walked into the office with a test suite of 10 tests that I had developed.
Monday also happened to be a big release for us; which featured a rewrite of the main application. My team promptly pulled the tests down, ran them, and noticed some of the tests were failing. I first thought I wrote bad tests, but I was quickly assured that there was a problem with the refactor. We quickly fixed the problem, watched the tests turn green one by one, and met the release deadline. I was all smiles that week and got a lot of “props” because of the errors that my tests caught.
This was a huge turning point for me. I went from cringing at tests to embracing them. Unit testing no longer seemed stupid to me, and I started to see value in writing tests. However, I still viewed tests as an added bonus not an actual coding practice. If you had time to do them then great, but they were most likely going to slow you down.
I started working for Callibrity about a month before I graduated college. My first client required that all code was developed using TDD methodology. Code changes were not allowed unless we had unit and integration tests to go along with them. At first this was a major struggle, largely because I was still in the mindset to write code first and tests later if there was time. Also, I realized I was really lousy at writing tests because I was never taught how to write a proper unit test. It took some time but with the help of my colleagues I, eventually, learned how to properly test my code.
Because we tested as vigorously as we did, It was rare that we ever encountered any production issues. However, when an issue came about we were able to recreate it with a test fairly quickly. With the new test in place, we added test coverage for a flaw in the system. This also allowed the tests to be a source of documentation for the bug that was fixed, and ensured that it never popped up again.
Fast forward to now. I have a newfound love for writing tests. Why you may ask?
- Tests prove my code works the way I intend it to
- Tests serve as documentation in code of the business rules that my code implements
- Tests make me write cleaner, more testable code
Oftentimes, I find myself turning first to my test cases to learn or remember exactly what this class does. Source code, of course, should still be readable enough to figure out how the application works; I just prefer to start in the test suite first when looking for answers.
My viewpoint on test driven development has done a complete 180 from when I started my coding journey. It baffles my mind that at one point I hated writing tests. Writing them first has become second nature and has made me into a better programmer. It forces me to take a more tactical approach and design an elegant solution. I have found when I write my tests first, I spend less time debugging and working on production incidents. This, in turn, gives me more time to do what I love: writing code and solving problems.
