Difference between revisions of "TDD2012"
| Line 22: | Line 22: | ||
Can write tests only after initial design, when in "bug-fix" mode - Pavel | Can write tests only after initial design, when in "bug-fix" mode - Pavel | ||
| − | Painful to retrofit tests - see Working Effectively with Legacy Code, Feathers | + | Painful to retrofit tests - see [http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 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 | 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 | ||
| Line 41: | Line 41: | ||
Jeffrey - Pair partner is both conscience (did you write a test?) and gives you permission (OK not to figure that out now) | Jeffrey - Pair partner is both conscience (did you write a test?) and gives you permission (OK not to figure that out now) | ||
| + | |||
| + | How about performance? Should run thousands of unit tests per second, but existing code may be too slow (Henk: reading file stream one byte at a time), need to revise | ||
Revision as of 00:37, 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)
How about performance? Should run thousands of unit tests per second, but existing code may be too slow (Henk: reading file stream one byte at a time), need to revise
