Difference between revisions of "TDD2012"
(Created page with "How deep to go in TDD? What do you mean by deep? Have to mock a lot, could have a million assertions [http://www.growing-object-oriented-software.com/|Growing Object Oriente...") |
|||
| Line 3: | Line 3: | ||
What do you mean by deep? Have to mock a lot, could have a million assertions | What do you mean by deep? Have to mock a lot, could have a million assertions | ||
| − | [http://www.growing-object-oriented-software.com/ | + | [http://www.growing-object-oriented-software.com/ 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 | ||
| + | |||
| + | [http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html 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 | Have to have a mock for everything not in this class -> listening to code | ||
| − | Brian Marick, | + | [http://www.exampler.com/old-blog/2003/08/21/ Testing Quadrant] - Brian Marick, classification of tests |
Jeffrey - earlier projects rescued by tests | Jeffrey - earlier projects rescued by tests | ||
| Line 15: | Line 19: | ||
* One project's code was bad, acceptance tests correct, rescued by running ATs and fixing | * 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 | * 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 | ||
Revision as of 00:32, 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
