# Experiences of test-driven devleopment in large projects

I've used TDD in personal projects, but I wondered if anyone had any experience of using this approach across a large team? Was there resistence to the test-first approach? Did you keep code coverage high for the whole project? How did coverage survive fixing those two-in-the-morning-and-you-ship-in-four-hours crash bugs? Did you run tests on all platforms, or just assume that passing on one meant passing the others?

I love the decoupled code that TDD produces, and the large suite of regression tests you get for free, but if you only have a few in the team who don't want to contribute tests, won't everyone suffer?

• Seems like this should be posted on StackOverflow or rephrased in a way that's more specific to tdd in large game development projects. Jul 30 '10 at 16:27
• "if you only have a few in the team who want to go old school, won't everyone suffer?" -- Are you saying TDD is old-school? If not I'm not understanding the sentence. Jul 30 '10 at 16:28
• @gaminghorror No sorry I mean if you have a few who don't want to participate in TDD. Jul 30 '10 at 16:36
• @jdeseno well that's the question. does the adoption of TDD have game-project-specific problems? maybe it's all fine! Jul 30 '10 at 16:56

Games are notoriously hard to unit test, so I really can't imagine this working out all that well. Also games are not spec-driven. Sure, maybe some low-level components are, but game logic itself is driven by the needs of the designers. The parts of your code that would code usefully do TDD with are also the parts you should probably use a library for (file formats, networking, etc).

• I absolutly disagree. TDD isn't driven by specs any more than any other piece of programming is. The tests aren't testing features, but grainular changes in code. I'd imagine you'd have issues testing at the hardware level, but there's no reason regular game logic couldn't be derived through TDD. Jul 30 '10 at 17:02
• In order to test something you need to know what it is supposed to do. Unless you have an assertIsFun() call somewhere, I'm not sure how that will work out. You can certainly write tests for game logic, but how does that help you other than having to make every change in two places (the real code and the tests)? Once the system is closer to being finalized it can be helpful to avoid accidental breakages, but thats very different than TDD. Jul 30 '10 at 18:21
• No-one practising TDD would ever write an isFun() test, and yes you have to make every change in two places - first in the test and then in the code. That's the entire point of TDD. Jul 30 '10 at 18:40
• No, the point of TDD is that you write your tests to the spec and write your code to the tests. When you have nothing to write the tests against, there is no reason to use TDD unless you really enjoy tedium. Jul 30 '10 at 18:53
• I'm sorry that's completely wrong. You're writing tests to express the functionality of the lines of code you want to write - you can want to write that line because of a higher-level design doc or not. In order to test something you need to know what it is supposed to do -- I'm not sure how you write code, but I know what I want it to do before I write it whether I'm using TDD or not. Jul 31 '10 at 9:05

The Arianne project had rather bad experience with people writing their tests first and concentrating on implementing something that fits their tests. This may lead to a lost focus on the bigger picture. And it gets a real issue if those people refuse to look at user visible bugs in their code because the tests are green.

From our experience it is way better to write the tests in parallel to writing the program. This way you concentrate on writing code that fits the general requirements and not just the return value of a method. But writing the tests in parallel to the code (instead of later) will result in code that is well structured for easy unit testing.

Automatic low level tests are very important for two reasons: They speed up development because small parts can be tested without starting up the complete application. And they can catch unintended changes done at a later time.

But they are no substitution for high level tests done by other people than the person who wrote the code. If the person who wrote the code made wrong assumptions it is likely that those wrong assumptions are in his own tests, too.

Keeping the team motivated works best when the member belief in automated testing and there is some progress visible: Public coverage and number of tests chart can be helpful. And of course it is a good idea to praise people for writing high quality tests (e. g. no bogus tests for the sake of stats).