TDD Will Speed You Up, Not Slow You Down
Is Test-Driven Development slowing you down? It shouldn't be.
Join the DZone community and get the full member experience.Join For Free
I was recently having a discussion with fellow Zone Leader Duncan Brown about TDD. He dropped this line:
"TDD rules — when you don't have a brand new product with a stupid deadline to work against"
This is the kind of argument I hear quite regularly from partial TDD proponents. They think it's great and love the idea, but they're too busy/under too much pressure to write code this way.
I think there are two fundamental flaws to this thinking, primarily that tests are an optional, nice-to-have thing. If this is you then I beg you to stop right now. Sure, if you just go straight head first into coding then you'll eventually get a working solution, and maybe you'll get lucky and it'll work perfectly as expected (although I suspect there'll be corner cases that will creep out the woodwork at a later date). But the reality is this code will not be maintainable.
Unit tests create natural documentation. Test names can read as a list of requirements that the code must satisfy. It becomes obvious why you've used a flag here or a convoluted statement there. Tests try to prove the code is correct, but also provide living functional documentation about what the code should do and why.
Perhaps you already know this but you're getting paid for your current job and long term maintainability isn't in your interest as you'll be handing the code off to someone else to maintain (let's ignore the fact that you'll be creating a legion of developers who want to hunt you down when they come to support your code). Well, here's the second reason I believe your thinking is flawed-
TDD should be faster than non-TDD.
Now, I'm not saying this will be the case from the moment you write your first test. If you're a relative novice to TDD then naturally you will be slower than you were before. Any skill set takes time to learn and become better at. When a project first moves to operating using agile methodologies it will always go slower at first, until the team is comfortable at which point the cadence will start to increase. The same goes for TDD- do not abandon it because at first it's slower. Any new skill set takes time to become proficient
I've been using TDD for about 5 years now and I'm much faster at coding when using it than without. Case in point- I attempted to solve my recent code challenge and decided to just write it and not bother with tests, because I'm not perfect either. The end result was a horrendous spaghetti ball that barely functioned, and took a long time to write. I deleted the code, started again with tests, and had the solution crafted in almost no time at all. I've found this pattern to be the case again and again. Whenever I waver off the path of TDD I'm hit with unsatisfying, lower quality code.
Writing code without tests is challenging. To verify that the functionality works you have to either spin up the entire application or create a harness to push data through. This means you're having to manually express tests like corner cases, which is highly inefficient (and very short termist). If your code doesn't work first time (and let's face it that never happens) it means you have to debug the code. Normally, that means placing breakpoints in and tracing through the application. That's really slow! Debugging is hard, and requires you to keep a lot of state in your brain- all of which disappears when someone comes over to ask you something.
TDD provides small chunks of tests with nice names, so then if you're distracted you can come back to it and be productive quickly. It's immensely satisfying, with little serotonin bursts every time you make a test go green. You also have the happiness of knowing that your code works because you've written tests. On top of this, TDD results in beautiful, well-separated code when done properly. And with rare exception will you ever need to use a breakpoint.
If you're not a fan of TDD I can understand (and politely disagree with) that. However, if you're using the excuse that you don't have enough time, I implore you to try harder. I think within a month or two you will find you're going faster than you ever did before.
Opinions expressed by DZone contributors are their own.
From CPU to Memory: Techniques for Tracking Resource Consumption Over Time
Top 10 Engineering KPIs Technical Leaders Should Know
Personalized Code Searches Using OpenGrok
DevOps in Legacy Systems