TDD2012

How deep to go in TDD?

What do you mean by deep? Have to mock a lot, could have a million assertions

Growing Object Oriented Software, Guided by Tests

Pavel - TDD not suitable for prototyping

Henk & Jeffrey - works for them, aids in figuring out what code should do

Clean Room development, Feathers - similar thinking about what your code should do but no tests

Have to have a mock for everything not in this class -> listening to code

Testing Quadrant - Brian Marick, classification of tests

Jeffrey - earlier projects rescued by tests

• One project's code was bad, acceptance tests correct, rescued by running ATs and fixing
• Another project had good code in Java, porting to Ruby; ported tests first, then wrote code until tests passed, smooth process

Can write tests only after initial design, when in "bug-fix" mode - Pavel

Painful to retrofit tests - see Working Effectively with Legacy Code, Feathers

Does writing tests make you think less hard? Lets you decouple and delay decision about implementation as you are focussing on output. Henk - makes me think more, consider design and API

Do you use pairing? Not currently, feel I need someone at same experience level to go fast - PJ has a talk on pairing styles including how to work with differing skill levels

Some people don't always write tests if few customers or code is for fun

Jeffrey - experience writing fun code for robot wars competition, expectation about quality of code != actual quality, so always writes tests

Do you find TDD lets you think less? Decouples and lets you delay implementation decision

Henk - makes me think _more_ about design and API

Jeffrey - maybe thinking hard but about _fewer things_

PJ - Don't write production code without a failing test

Jeffrey - Pair partner is both conscience (did you write a test?) and gives you permission (OK not to figure that out now)