I first began programming professionally a few of years before I took the Test-Driven Development training back in 2013.

Honestly, I didn't know much about the training since it was organized by another member of our team. We had a training budget, and we had to use it. Our small team of about 10 had worked on some significant projects, and we were actively managing a very large (1M+ LoC) codebase. We were already shipping our systems for years. However, we started to feel growing pains. More projects and more team members, yet no testing. That's a recipe for pain. We were stepping on one anothers toes, breaking long established libraries, shattering our confidence in what we expected to work. We knew we needed testing, yet we had still had doubts over TDD. After all, some of us were well-seasoned developers, so what additional value could TDD possibly offer?

We took the training with James Grenning over several days, heavily influencing the handling of our future projects. Personally, it has helped expanded and grow my career as a software engineer. TDD requires discipline, and only those committed enough to endure the initial pain of harnessing their new and legacy code will greatly benefit. And so, at the beginning, discipline and the willingness to change your old bad habits and development style is critical.

After having done the TDD training, and having exercised it in my career over the years, I have come to appreciate the following key benefits:

First, TDD will make you a better software architect. In a large project, TDD forces you to think about architecture, to pay attention to the testable boundaries and interfaces between blocks, components, libraries, etc. It emphasizes your perspective back on the user of your software, not the developer, forcing you to organize your code well. As a consequence, it doesn't allow for spaghetti code (not easily at least!).

Second, TDD will make programming more enjoyable. One of the few things that stuck out to me was when James Grenning, our instructor, said that the immediate feedback loop you get from doing TDD will make programming much more enjoyable, and he was completely right. So many things in our life require feedback, and the more frequent the feedback is, the more motivated we become. If you're working on a major project without TDD, it may be weeks or several months before you get any practical feedback about how your code is performing, causing you to lose focus, motivation, and maybe even languish in your effort. With TDD, you get feedback as soon as you have your test-harness made and ready. It's a beautiful thing!

Third, TDD is a transferable philosophy. Although my original TDD training was with James using the CppUTest unit testing framework for embedded C/C++, my career has now taken me into the high-level cloud computing realm as I work on web-based applications in C/C++, python, and javascript. TDD is widely supported in many programming domains and a variety of languages, making the core TDD ideas and concepts from James' training easily transferable.

Finally, I want to emphasize what I believe is its greatest benefit: TDD enables you to safely scale a growing project, freeing you from any fear and hesitation about refactoring it. And as any experienced software engineer will tell you, refactoring is inevitable. The business scape is always changing, and your project better be prepared to handle future growth. If you're not committing to use TDD in your project, then you're not committing yourself and your project to grow.

Happy coding!