View source for TDD2012


See also notes from the [[TDD]] session from 2009

[http://coderetreat.org Global Day of Code Retreat] 8th December 2012

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 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

[http://www.exampler.com/old-blog/2003/08/21/ 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 [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

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? [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?

Jeffrey - one dev wrote tests because he didn't trust colleagues, they broke his code and he could detect right away, eventually said "how do you know? [CI & tests] oh, we should all do that"

Pavel - wants to know about changes, continuous testing tells him about them

Relative salary of dev & testers can be a motive for testing

Jeffrey - Scott Ambler discussing pairing with CTO, polled team, only 20% had code on screen & looking at it, so pairing would double productivity

These are not personal motivations;

Personal motivations:

* "to be less wrong"
* not to be in debugger
* not get stuck
* Want not to be afraid of refactoring
* want to change code with confidence
* feel safer
* avoid angry emails from customers
* not find from "git blame" that the jerk who wrote the awful code was yourself
* love experience of writing code for 4 hours, check in, works first time

Jeffrey - at Agitar, didn't want generated tests for their own code (because of course it was fine) but to protect themselves against someone else breaking their code

How do you convince others to adopt TDD?

Jeffrey - Crossing the Chasm and what motivates change

* Early adopters adopt TDD because it's better - only 15% of world
* Later adopters have to have it solve a live problem for them

Easy to "make" some teams use TDD, others harder, especially third parties, as they are not convinced - Jeffrey "not a problem for them"

Coding dojo to practise better methods every couple of weeks, majority accept that this works, six months in most are still doing unit testing

Squirrel - "Convincing" people wrong mindset, help team to solve problems that they observe

Writing tests that pass is like sex - after you have it the first time you never look back