TDD in an large project: How do you get started?

Question

Simple question. Let's put on our engineer/project manager hat for a second:

You have a large project and you will have several different developers working on different parts. You have a solid functional spec and are ready to start figuring out your implementation. You want to practice Test Driven Development. Assume you will be given reasonable but not infinite time and money.

How do you start preparing the modules for implementation by the other developers? Do you start writing interfaces or do you start writing tests? Do you mix n' match?

How would you change your answer if you had a team of veteran coders? A team of less experienced folks? Would your coding environment change your decisions?

Answer 1

If you have a good functional spec, I'd split the work...and start working on test cases.

Once you've got the test cases worked out, the developers can begin coding their modules and the tests to go with them.

...and the approach wouldn't change with different developers or coding environment.

Answer 2

Strictly speaking - if you are doing TDD (not just Unit Testing) then you start with the tests first before writing the function that the Unit tests actually test. All functionality that you write needs to have tests written to verify the code that you are about to write.

The developers themselves would be the ones writing the unit tests - functional/acceptance tests are a separate issue and could be (partially) written prior to work commencing.

If the team is not experienced with Unit Testing, they should start implementing features and then writing Unit Tests as soon as each little class/small piece of functionality is finished

Unit Tests (and TDD as a result) are not to test modules of systems - they are to test at a more granular level - that is that functions and classes do what the dev expects them to. Testing at a higher level is outside the bounds of TDD, and stepping into other types of tests

Answer 3

In traditional development (non TDD), between having a functional spec and writing the first line of code there is a lot of designing involved. You would still need to go through this process and this definitely depends on the skill level of the team. The only thing that would be different in TDD is to write the test cases just before writing the code. You obviously cannot write the tests without knowing what classes/interfaces are involved.

Answer 4

TDD isn't exactly what you're looking for. TDD happens at the beginning of the project and drives development, hence Test Driven Development.

What you're likely looking for is a test writing strategy. From being on numerous big projects that have implemented testing later on, here are some tips:

• Start small. Don't try to get 100% coverage on the entire project, choose one class or one set of functions and begin there.

• The impulse will be to start with your smallest/simplest class/functions just to get some quick wins and have code coverage at 100% for one file. Don't.

• Instead, as you get bug reports and fix them, write tests to support yourself. It becomes an incredibly effective exercise to write tests to demonstrate bug, fix bugs, run tests and not see a bug.

• As you get new feature requests, write tests to support yourself. It's the same effect as fixing bugs.

• Once you have a few tests written, run them continuously. There's no point to having tests if they're all broken and/or not being run.

True, you don't end up with 100% code coverage, but you can steadily and regularly apply more and more tests and after a dozen bugs or so, you'll have quite a few useful tests. And more importantly, you'll get more and more tests is the "worst" or most problematic areas of the system. We're doing this now with web2project: http://caseysoftware.com/blog/unit-testing-strategy-web2project.