Is Test Driven Development a flawed process?

[Paul]

I ‘ve read some interesting opinions on TDD recently. Both developers and testers have argued that one of the main issues with TDD is that when requirements change (and that usually happens) you have to go back and change the tests before you change out your code.

From a developer perspective, it’s more about the less is more. Testing too soon in the lifecycle, developers argue could change direction of development and that testing should start when there is a stable design. As well as that if code is only being written to pass tests, then this might encourage bad overall code as the focus can become to pass the tests rather than the full design.

Is TDD too rigid a system? Is it that TDD is suited to a very specific process (large projects with well-defined requirements) or is it being overly criticised? What do you think?

[Rajit]

I’m familiar with TDD as practiced by developers. In fact I’m not familiar with any form of TDD practised by testers.

Is TDD too rigid a system?

TDD’s as rigid a system as you make it. If you understand what you gain/lose by doing it, and what you gain/lose by not doing it, you’re well placed to make the decision for yourself.

The best way to understand this is to practice it a lot. I recommend using code katas: http://codekata.com/

testing should start when there is a stable design

Testing is the main tool we have to learn about what we’re building. If we wait to test until the design is stable, how can we claim at all to know what we’re doing? Would this ‘stable design’ be any good?

What do you gain by doing TDD?

Design tailored more to its use than to its implementation

With TDD, when building something, you: declare what you want to achieve, implement it minimally and then refactor. Since the use comes first, you can think of this without being impeded by implementation details. How do you want it to work? Do it that way.

You only implement what you need

TDD has been good for me when I’ve been surprised by how little I needed to implement to meet the requirements. It’s great that “ability to schedule job once a week” makes you drool with thoughts of the great scheduler you know you could build. If they only need a fixed time once a week do you really need a fully general scheduler?

Clean, maintainable code

This is not a guaranteed outcome by any stretch of the imagination. I’ve found mainly from performing code katas that I have learnt how much refactoring I should be doing, and how much refactoring I should not be doing. This is something that fits amazingly well into TDD. Refactoring and tech debt are difficult challenges that team after team struggles to overcome.

So what do you lose by choosing to use TDD? If you’ve written lots of tests and the requirements change, are those tests now a burden? That’s really a question around how reliant on those tests you are. To answer that you’ve got to look at your whole strategy to testing.

The “open-closed principle” states that modules/classes in code should be open for extension, but closed for change. Hypothetically, a change in requirements leads to new code (as an extension of existing code, or as a replacement) rather than just hacking away at it and hoping it still works.

I do think the TDD process can get in the way of learning a new technology. In all likelihood you just want to experiment, and don’t necessarily have even hypothetical requirements at the front of your mind. Likewise if you really don’t know how you’re going to implement something, you might benefit from spiking it first and then using TDD to build it.

[Alin]

Hi Paul,

TDD is clearly a different approach for software development lifecycle.

Paul wrote:

testing should start when there is a stable design.

In practice, there are little chances that a stable design would be available because the stakeholders want many features as soon as possible and the requirements are changed frequently. Incomplete information or unclear data in requirements may also impact the design. That’s why the tests are started even if the design is not stable and the tests are changed often.

Paul wrote:

code is only being written to pass tests

I agree with this idea and this is the focus on TDD. The advantage means that is less likely to introduce bugs into production code and generally I have seen that projects that use TDD have very few bugs discovered on production.

I cannot say if TDD is a rigid system or not. I think it must be tailored to each project and it depends on the context. Both small companies and large companies can use TDD. What I find very important is the understanding of the concept. The team must be adapted to use TDD and it needs fully commitment from the team members to apply it. It might take some time till the project will gain advantages from using this approach.

Regards,
Alin

[Fiona]

If you are not practicing TDD or Extreme programming(XP), then your process is probably some form of the waterfall model.

[Author]

Posts