Difference between revisions of "TDD2012"
| Line 25: | Line 25: | ||
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 | 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 | 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 | ||
| Line 33: | Line 31: | ||
Jeffrey - experience writing fun code for robot wars competition, expectation about quality of code != actual quality, so always writes tests | 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) | ||
Revision as of 01:35, 20 October 2012
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)
