Over a million developers have joined DZone.
Platinum Partner

A Hardheaded View of TDD

· Agile Zone

The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.

I had a chance to pair with Llewellyn Falco last week at Agile Open Northwest. Our approaches to test-driven development are pretty different, so we had some interesting conversations on the nature of TDD. In a followup email, Llewellyn said that his takeaway was that I don't see tests as specifications for my app. To which I responded:

You're absolutely correct that I don't see TDD's tests as specifications. I see TDD and its tests as a tool with three benefits:

  1. Helping me write correct, usable code now
  2. Alerting me and others to errors when we change or add code
  3. Helping us understand the original intent of my code

My approach to TDD is focused on maximizing these three benefits while minimizing the cost of writing and maintaining the tests. Specification isn't part of the picture. (It has value, but it isn't what I use TDD for.)

I may have missed a few of the benefits of TDD in that response, but I think it's essentially correct. I take a hardheaded view of TDD. For me, TDD's tests aren't an end worth pursuing. They're a tool that gives me certain benefits: a check on my work, a suite of regression tests, and code-level documentation. Other than that, they're waste to be minimized.

The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Learn more about driving business innovation by leveraging Agile quality lifecycle strategies.


Published at DZone with permission of James Shore , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}