Test-driven development (TDD) is a tremendous approach for writing reliable software programs, but it's not a tremendously intuitive one. I recently asked the question What was your TDD aha moment? and I want to share the top comment, which provides good insight into the subject.
One of the biggest "aha"'s I've had was when working on a legacy codebase with very few unit tests.
I needed to change the behavior of a couple of methods, but I wasn't super sure what their current behavior was to begin with.
A lot of folks would reach for their debugger and spend the next while meticulously stepping through the code. But that felt slow to me...
So I put together a suite of tests around them (prior to making any code changes) to verify and document what they were really doing. Once that was done, the overall change was as simple as adjusting a couple of assertions, causing those tests to fail and reimplementing the methods to meet their new expectations.
It's one thing to see TDD as a way to confidently write a brand new feature, it's a whole other ballgame to see it as a way to confidently navigate and tease apart legacy code. It was like being in a super dark tunnel, and finding a flashlight. Literally everything got easier.
And don't even get me starting on working on an old codebase with a good suite of tests. Pure. Bliss.
Early in my software career I struggled with imposter syndrome over the fact that TDD had not clicked for me. It's okay to not TDD. Most developers do not use this approach.
Still waiting. 😂
TDD is one of the finer approaches for software development, but don't stress if it has not clicked for you.
If you're interested in getting started with TDD, this post may be helpful:
I’ve sent a message to my family and delegated my open source projects to my friends. With my last tweet sent, I turn off my laptop, phone, and tablet. My Digital Sabbath begins in 10 minutes: no digital devices for the next month.