Difference between revisions of "TDD2012"

From CitconWiki
Jump to navigationJump to search
Line 43: Line 43:
  
 
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
 
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
 +
 +
Pavel - we do continuous delivery and find that you need to have tests for every change; don't deploy if this is missing
 +
 +
How do you motivate yourself to do TDD? [http://www.butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata Screencast from Uncle Bob] and similar examples can be motivating
 +
 +
Other examples: [http://www.jamesshore.com/Blog/Lets-Play/Episode-176.html Jeff Shore Let's Play TDD], [http://pairwith.us PairWithUs]
 +
 +
Do brainteaser for every bug: how could I have written a test for this bug?

Revision as of 00:41, 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

Pavel - we do continuous delivery and find that you need to have tests for every change; don't deploy if this is missing

How do you motivate yourself to do TDD? Screencast from Uncle Bob and similar examples can be motivating

Other examples: Jeff Shore Let's Play TDD, PairWithUs

Do brainteaser for every bug: how could I have written a test for this bug?