4

Chapter about TDD from Martin's "Clean Code" caught my imagination.

However.
These days I am mostly expanding or fixing large existing apps.
TDD, on the other hand, seems to only be working only for writing from scratch.

Talking about these large existing apps:
1. they were not writted with TDD (of course).
2. I cannot rewrite them.
3. writing comprehensive TDD-style tests for them is out of question in the timeframe.

I have not seen any mention of TDD "bootstrap" into large monolite existing app.

The problem is that most classes of these apps, in principle, work only inside the app.
They are not separable. They are not generic. Just to fire them up, you need half of the whole app, at least. Everything is connected to everything.
So, where is the bootstrap ?

Or there is alternative technique with results of TDD
that'd work for expanding the existing apps that were not developed with TDD ?

Andrei
  • 8,606
  • 10
  • 35
  • 43

3 Answers3

3

The bootstrap is to isolate the area you're working on and add tests for behavior you want to preserve and behavior you want to add. The hard part of course is making it possible, as untested code tends to be tangled together in ways that make it difficult to isolate an area of code to make it testable.

Buy Working Effectively with Legacy Code, which gives plenty of guidance on how to do exactly what you're aiming for.

You might also want to look at the answers to this related question, Adding unit tests to legacy code.

Community
  • 1
  • 1
Don Roby
  • 40,677
  • 6
  • 91
  • 113
2

Start small. Grab a section of code that can reasonably be extracted and made into a testable class, and do it. If the application is riddled with so many hard dependencies and terrifying spaghetti logic that you can't possibly refactor without fear of breaking something, start by making a bunch of integration tests, just so you can confirm proper behavior before/after you start messing around with it.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
0

Your existing application sounds as if it suffers from tight coupling and a large amount of technical debt. In cases such as these you can spend a LOT of time trying to write comprehensive unit tests where time may be better spent doing major refactoring, specifically promoting loose coupling.

In other cases investing time and effort into unit testing with Mocking frameworks can be beneficial as it helps decouple the application for purposes of testing, making it possible to test single components. Dependency Injection techniques can be used in conjunction with mocking to help make this happen as well.

maple_shaft
  • 10,435
  • 6
  • 46
  • 74
  • 2
    Let me stress that refactoring without having any tests to begin with is a recipe for disaster, which is why I stressed writing integration tests if nothing else, right up-front, so you can at least be reasonably sure that you're not totally breaking something while refactoring. – Daniel Mann Jun 07 '11 at 11:02
  • I thought integration tests were a given, my bad :( – maple_shaft Jun 07 '11 at 11:19