13

I work in a large company, but on a just two man team developing desktop LOB applications. I have been researching TDD for quite a while now, and although it is easy to realize its benefits for larger applications, I am having a hard time trying to justify the time to begin using TDD on the scale of our applications.

I understand its advantages in automating testing, improving maintainability, etc., but on our scale, writing even basic unit tests for all of our components could easily double development time. Since we are already undermanned with extreme deadlines, I am not sure what direction to take. While other practices such as agile iterative development make perfect since, I am kind of torn over the productivity trade-offs of TDD on a small team.

Are the advantages of TDD worth the extra development time on small teams with very tight schedules?

Improve this question
1
  • what does LOB stand for? Line of business?
    – gnat
    Dec 25 '11 at 19:25
14

The ugly truth is that initially it will slow you down. Any new process or practice takes sometime to ramp up on. In my experience TDD doesn't payout with initial implementation as much as it does with maintenance, bug fixing and extension. I know for others there is an immediate payout, so it will depend on each person's current coding style.

While I am a huge proponent of TDD (I brought it in to my current job) I think you need to have a little breathing room (deadlines/timelines) in order to explore and understand the practice.

The smaller your team the more immediately you can benefit from TDD. I've seen this payout in team size from 6 to 3.

Improve this answer
4
  • 2
    +1: it's not about saving in development time, it saves (a lot!) in debugging and maintenance time.
    – Javier
    Dec 25 '11 at 1:38
  • 4
    "If you think test-first is expensive, try debug-later"
    – Ryan Bigg
    Dec 25 '11 at 4:46
  • @Ryan Bigg: I agree that unit tests are a great support to debugging but well-written code is really not difficult to debug with a traditional debugger.
    – Giorgio
    Jun 20 '13 at 19:08
  • @Giorgio: code can be as well written as possible, when you cannot test it in isolation because of missing infrastructure around that code, the test/debug/change/test again cycle needs just more time. That's specificially true when you are searching for a bug where you don't know the root cause, and you don't know where in your 100K lines of well-written code the failure may be.
    – Doc Brown
    Oct 1 '13 at 6:18
10

The extra development time you are talking about may be an illusion.

What makes TDD different to standard unit testing is that it's not just used to make tests.

TDD is a new way of developing software. It is one of the best way I know.

Therefore, it is not related to the size of your project. You will extract the benefits from the first line of code.

  • it will force you structure your code in a way it will be easier to maintain and reuse. It drives the design of your software.
  • it will make refactoring fast, secure and enjoyable.
  • it helps you to write smaller chunks of functionalities that makes the implementation of tasks lot easier.
  • it usually makes debugging task less frequent.
Improve this answer
9
  • I was going to answer, but Pierre says it well. Start small, on something that you have to build anyway, and you should start the benefits the very first day.
    – Marcie
    Jan 29 '11 at 15:30
  • 2
    It may not be an illusion either. A new practice can take awhile to get spun up on. Especially if no one else is around who has done it. I would say it can go either way intially.
    – dietbuddha
    Jan 29 '11 at 16:49
  • @dietbuddha: I agree with that, I hesitated to put some disclaimer, but I wanted to put emphasis on the real benefits on TDD when well applied.
    – user2567
    Jan 29 '11 at 16:51
  • 1
    @Pierre - TDD seems to have a particularly nasty first step (and I speak from my repeated struggles to start) having suffered from the same problem i.e. too much to do and too little time. I don't need to be convinced of the benefits - but bootstrapping myself and then my colleagues is currently beyond me (you will have to trust that its not a lack of ability on my part...) - in part because of pressure of time and in part for not knowing quite how.
    – Murph
    Jan 30 '11 at 11:07
  • 1
    @Murph: Are you working on UI intensives applications? I tend to stop using it when I work on such applications.
    – user2567
    Jan 30 '11 at 11:33
8

common misconception, let me shout it out:

TESTS IN TDD ARE FOR FEATURES

EOM.

Edit: let me elaborate: "writing...unit tests for all or our components" is unit testing, not TDD. I routinely use TDD on one-man teams with great success; the payoff is extraordinary.

Improve this answer
1
  • 1
    common misconceptions, TDD generate project tests. The reality is TDD generate project specifications.
    – Display Name
    Jan 30 '11 at 11:21
3

There is a great book on TDD, The art of unit testing (official site) which has it's examples in .net with a java version on the works. The good part is that there are whole chapters considering issues such as "Integrating unit testing into the organization" - Chapter 8 and "Working with legacy code" - Chapter 9. Although I am not an expert on this field (yet :-) ), based on my experience I believe this is a good starting point.

The art of Unit Testing cover

Improve this answer
1

There's a couple of questions you need to get the answers for:

  1. How much time do you spend after release fixing bug in the the code? If you can quantify this you might find that it equals or even exceeds the "extra" time it would take you to write the test that would help prevent these bugs happening.

  2. How often does an apparently straight forward edit to refactor the code or add new feature broke something apparently unrelated? Again with good test coverage these can be reduced.

Even if you can't put exact numbers on these you should be able to demonstrate that you're spending this time anyway so you might as well spend it "up front" and (hopefully) end up with a much more stable product.

Improve this answer
1

When people talk to me about starting to adopt testing in their team, I always first check how the tests will be run. Often teams don't have a continuous build in place. If you have limited resources then I'd suggest that setting up a CI server is a prerequisite for starting any serious foray into testing.

Once you've got that setup then just start practicing TDD. Bear in mind that if the system hasn't been developed with testing in mind you might struggle to make exisiting code testable, and it is going to be expensive to restructure it.

Start by looking for easy places to start with TDD - new classes or modules, with few dependencies. Utility classes and data structures are often good things to start with.

Get a feel for how how it changes the way you think about your code, note how much better the code you produce is, and how much more confident you are about that code.

I know I haven't really answered the question, but I guess my point is that you should be able to do all this without a massive additional cost. In working through your first examples you'll better understand the advantages for your project.

Bottom line - slower development, but few defects, so much less time fixing bugs.

Improve this answer
1
  • 1
    One addition: Initially, look for highest value tests. Tests that let you know, early, you've broken your code base. These tend to be high, sweeping tests that don't tell you what you broke, but that you broke it. You'll very quickly see the value of a CI, with testing, environment. Use tests to debug breakage. With a system in place, the costs of adding new tests starts getting easier/cheaper and you can focus on more tests that do a better job of proving that it works and showing where it doesn't.
    – Jim Rush
    Jan 30 '11 at 15:20
0

Here's where I think Behavior Driven Development shows immediate gains, but I'm not sure that test driven development does.

In behavior driven development you approach your tickets in a different way: you sit down with the business person and work with them to define the behaviors that this chunk of functionality should have. I describe this in an entry on my blog, (the post title: Writing Behaviors).

Sitting down with the business person or whomever will help you and them to better understand what the system needs to do for everyone to be happy with that piece of functionality. What it needs to do to be able to be accepted by the QA process you have in place.

Defining testing criteria, then writing those testing criteria into your automated test suite, should reduce the amount of back and forth you get: someone claiming the functionality is broken, because you missed something (either because you legitimately missed something, or because they never told you about it).

It also may help other's perception of your team: if you sit down and define what needs to be done in the system, you could go from, "idiots who overengineer everything and spend time on things we didn't ask for", to, "smart folk who are coming up with useful features".

TL; DR: Behavior Driven Development may show improvements quickly because it's "customer" focused. Test Driven Development, to me, seems to be about testing internals of the codebase that "nobody" cares about and gives less obvious business benefits. (Behavior Driven Development has the immediate, in your face, change: the engineers are suddenly having a lot more face time with the "customer" or business analyst to try to get this right - which should be seen as a good thing. "Oh, they're having a meeting about Feature X, which means there's progress on that front!")

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.