Given a short (2-week) sprint, is it ever acceptable to forgo TDD to “get things done”? [closed]

Question

Given a short sprint, is it ever acceptable to forgo TDD to "get things done" within the sprint.

For example a given piece of work might need say 1/3 of the sprint to design the object model around an existing implementation. Under this scenario you might well end up with implemented code, say half way through the sprint, without any tests (implementing unit tests during this "design" stage would add significant effort and the tests would likely be thrown away a few times until the final "design" is settled upon).

You might then spend a day or two in the second week adding in unit / integration tests after the fact.

Is this acceptable?

Answer 1

A 2 week iteration isn't short for a lot of people. Many of us are doing one week iterations. Kent Beck is even trying to encourage daily deployments - and there are advantages in cleaning the dev process up so it can be that responsive.

NEVER reduce TDD quality to get stuff out - It's so much harder to clean up later and you just end up teaching the customer that they can pressure you into quick, dirty, hacked releases. They don't see the crap code that gets produced as a result - and they don't get to maintain it. If somebody tried to get me to do that I'd quit... and I have refused to work in places that "don't have time to test properly". That's not an excuse that works.

NOTE: When I write about TDD, I'm including functional tests. These are important because they should exercise scenarios that make sense to the customer in terms of recognizable user-stories. I normally start work on a story with the functional test because it's the most important test - "test customer gets what they described..." All the other tests might be up for negotiation, but when I'm team leading I expect at least one functional test per story or it's (as scrum people say) "not done!" ;-)

Don't think you can go in and add tests later - it's so much more difficult to do that. (I have tried it both ways - believe me.) It really is cheaper to put tests in as you go - even if you have to refactor and rewrite, or throw some away as the system evolves.

You can't get quality code without having decent code coverage ALL the time.

Code test coverage is the important word here. Covering stuff that could break, not just zillions of meaningless tests - critical tests that cover things you need to worry about.

If you can't get it out in time and it's a problem you need to think why?

• Is it a planning/release scheduling problem?
• Is there a code maintenance/refactoring problem that holds things up?
• Are there people putting unreasonable pressure on the team? (get the CTO to beat them up...)

Answer 2

I would say that it's almost always acceptable to bypass any process if it means that you complete a project that you wouldn't otherwise be able to complete. The processes should be there to help you, but if your process is not helping, then don't use it (after discussing it with the rest of the team first, of course).

However bypassing TDD can easily result in the exact opposite effect - you could write buggy code that just before you need to ship requires a rewrite as final testing shows up critical problems that you should have spotted sooner, so think carefully before doing so.

If you do skip unit testing to get something out the door and are lucky enough that it works, you should see it as a technical debt that should be paid back as soon as possible.

Answer 3

If you can accurately code something without tests, why use unit tests at all? Unit tests should either help you write code faster or help write better code. If it doesn't do either, don't use unit tests.

Answer 4

In my experience, writing proper unit tests take at least as long as writing the code that it tests, so I have a hard time seeing how you're going to write tests in "a day or two".

That said, what is "acceptable" depends on a lot of things. Don't treat testing as a religious issue. The tests exist to give you a certain level of confidence in your code. You just need to realize that by foregoing testing you are also increasing your risk. Sometimes this is appropriate, other times it isn't.

The two extremes to be careful of:

• Saying you'll write the tests later, and then never getting around to it. This is "borrowing from the future", and you can quickly accumulate more debt than you can pay back.

• Spending more time on testing than warranted. There are certain risks that are so small that there isn't any point in testing for them if the expected cost of something going wrong is less than the cost of writing the test.

Answer 5

To my mind this can be a dangerous trade-off to take. While it may be acceptable some of the time, it does set a precedent that can be hard to overturn. I know where I work, for some complicated things, we tend to have to implement something a few times in order to finally arrive at a good implementation as the idea of something better tends to come along every so often in our project.

Usually, it is in building the tests that missing requirements can be caught and that a more complete design can be drawn initially before getting a lot of code as otherwise there is a pile of code that one may want to try to reuse so much rather than throw away and build something better from scratch.

The key is to be able to follow through on those tests in the second week rather than focus on something new that seems to be a priority one work item. While this can be fine for some, for others it can be a recipe for disaster, IME.

Answer 6

From your description you aren't really doing TDD, since the tests are not driving the design. It is more the case that you are doing unit testing, which is still a good thing.

In terms of the basic question, can you forgo tests, really this is something that only experience (of the team) can guide you with, in terms of what is the tradeoff. Generally you come to regret it, but sometimes a quick bad hack is better than not delivering at all.

Answer 7

Maybe I'm missing something, but you're either doing TDD according to the generally agreed principles, or you're operating like a TDD cargo-cult.

If your team/company has made the decision to use TDD, and intends to stick with it, you either need longer sprints, or you need to reduce the amount of functionality to be completed within the 2 weeks.

Answer 8

implementing unit tests during this "design" stage would add significant effort and the tests would likely be thrown away a few times until the final "design" is settled upon

I've found that Test-Driven Design takes me to the final "design" faster: in fewer iterations, and often the first shot is the last. Design iterations are normally needed because the program is designed without any reality checks, and subsequent implementation efforts and attempts at use drive the redesigns. With TDD, the reality check is in place all the time. That can be enough to make sure you don't miss the mark and have to redesign the thing.

Answer 9

If you are not shipping code then what good are you as a developer? The most important thing is to get code in front of your users. If is means sacrificing one part of the process to complete a project then do it. The CEO is not going to give you a bonus for implementing TDD and not shipping.

Answer 10

Good tests double the time it takes to finish. If the management team dings you for taking longer, well then, this is where the metal hits the meat in real life projects, isn't it?

I find TDD to be a zealot's practice, wastes time making tests fail, the compilation errors, refactoring tests and code to death, and the like. In the end, as long as you get good test coverage of the code you can save time by creating unit tests immediately after the feature compiles and starts to work.

Answer 11

This is a business decision rather than a technical one. Does the code need to truly work or just look like it works?

Here is one time it would be acceptable:

You have a new product that hardly anyone is using and your head sales person is going to some industry conference to demonstrate it. You trust her to dance around any bugs you leave in. The conference will build interest in your product and sales will flow in the following 3-6 months. Your company has 8 months cash left in the bank.

Here is one time it would not be acceptable:

Your code controls x-ray hardware in 5,000 hospitals. You are rolling out a new version. You don't want to kill people. Your company will be sued into oblivion if you make big mistakes.

There is a speed to development vs quality tradeoff to be made. That is a business decision. Let's hope you've got a manager willing to understand that.