DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > The second D in TDD

The second D in TDD

Jens Schauder user avatar by
Jens Schauder
·
Jan. 11, 12 · Java Zone · Interview
Like (0)
Save
Tweet
5.65K Views

Join the DZone community and get the full member experience.

Join For Free

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).

 

From http://blog.schauderhaft.de/2011/12/25/the-second-d-in-tdd/

Software design

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Is High Cardinality?
  • Understand Source Code — Deep Into the Codebase, Locally and in Production
  • Legacy Modernization and Hybrid Cloud with Kafka in Healthcare
  • A Simple Guide to Rust Data Types

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo