Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 89 posts at DZone. You can read more from them at their website. View Full User Profile

The second D in TDD

  • submit to reddit

Some proponents of TDD say, that TDD forces you to find a good design. Some even translate TDD to Test Driven Design. I don’t agree. Mostly.

Lets start with the small part where I do agree.

Since TDD forces you to write test first, it forces you to think about how you want to use an API, because that is the very first thing you write down. This is a good thing and in my case led to more usable APIs (often in the form of Builders or little internal DSLs).

Since it is almost insane to test anything if it isn’t properly decoupled from stuff it uses, TDD also forces you to factor out dependencies in order to be able to mock them. Thats the other point where TDD encourages good design.

But there are bad news: There is more to software design than just nice to use APIs and SOLID principles: Your design actually has to solve a problem! And TDD does almost nothing for you in order to find a good solution for your problem. Yet this is really the hard part in software design.

Can your domain model represent all the cases needed by the business? TDD won’t tell you.

Should represent some edge cases of the domain in a ‘dirty’ way and thereby making the domain model simpler and therefor 99% of the use cases way easier? Or should you go for the complete but awfully complex solution? TDD won’t tell you.

Which of all the design patterns would help you? Or is there some well known algorithm you could use to solve your problem? TDD won’t tell you.

Does the problem become trivial once you approach it in a functional way? TDD won’t tell you.

Is recursion a solution or a dead end? TDD won’t tell you.

You have to understand the problem and know lots of possible approaches to a problem in order to design software well. There is just no way around it.

Once you have the solution in your mind, once you know the basic data structures and algorithm you going to use, TDD will help you to implement it in a clean, well factored way. It will also help you to stay focused on the task at hand (which is making the next test green).



Published at DZone with permission of Jens Schauder, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Tech Fun replied on Wed, 2012/01/11 - 7:50am

For sure TDD is not a silver bullet to all your problems at hand, but at coding level and micro design level, it's the best practice ever.

Jeff Dickey replied on Sat, 2013/12/14 - 12:58pm

Too many people, generally those with lighter technical backgrounds, expect one thing to be The Silver Bullet That Does All, Sees All™, and when it isn't, they go into full backstabbing mode. "TDD won't fix my breakfast and fold my shirts!" "Well, maybe you need more than one tool. An iron, perhaps."

I've been doing software professionally since the late 1970s. I've been doing some form of what's now called "Agile" since at least 1986, with a success rate of well over ninety percent. What's the secret? Communication, versatility, communication, shared understanding, communication, having more than one tool in your toolbox. The saying "when the only tool you have is a hammer, it's easy to think everything is a nail" predates electronic computer software development by decades, but it's been a constant for longer than I've been alive.

When you don't invest in your people; when you don't insist on lowballing every single line item — no team training, for instance, or no technical writers or quality engineers because "agile means you do it all", You're Doing It Wrong. You're doing it so wrong, that if you're lucky enough to recognise how badly you've broken things while they're still recoverable, you might hire me or one of the dozen or so people I've met like me who are actually pretty good at software necromancy. That's not to say we, or anybody or anything, is a sure thing; if you're honest with yourself as you learn more, you realise the infinite expandability of what you don't know. Failing to realise that, or admit that it applies to you, too, is the second-most reliable way yet found to kill otherwise-promising software projects and destroy teams.

If you're a reasonably buzzword-compliant marketing-driven manager, you've heard of "continuous integration" and "continuous deployment". You're far less confident in your knowledge of "continuous training" or "continuous improvement", but you "know" they're "too expensive" for your "simple" project. That is the software world's analogue to the Dante quote that reminds us that "there is no man in the world so piteous, as the slave who falsely believes himself to be free". Don't be that slave, or make your organisation into one!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.