TDD

Notes below from CITCon Europe 2009: http://www.citconf.com/wiki/index.php?title=CITCONEurope2009Sessions

See also the notes from Budapest TDD2012

Main Points

Without TDD, you write bugs faster. With TDD, you write code faster.

With TDD, you write *working* code faster. That's a better definition of TDD

Summary

Here's a very patchy summary of discussions that occurred in this session:

Maridn: can't write test first, code won't compile

Joe: anecdote of how TDD works - 10 minute cycle

TDD results in emerging conception

Joe: start with unit test

Antony: outside in, look at the acceptance test first. then write unit tests

Refactoring Testing book: recommends refctoring legacy code last. Hard to do, can't drive legacy code

Andy: it is possible to add new features to legacy code, break off the new bit into a small testable chunck.

Who should write the acceptance tests for TDD? The team?

Antony: customer tests first. BDD. Start with Acceptance tests

http://pairwith.us

People who are new to TDD: how did you learn about TDD?

Hard to learn habits

Best way is to learn the coding dojo

Much easier to introduce TDD to junior developer

Experienced developer harder to change

The best way of learning TDD is by doing it

Example: driving TDD into an existing company

Training sessions

coding dojo - didn't work well on legacy code

better to abstract away legacy code - wrap legacy with an interface, and work to that. Example of strangler fig.

Wrap older legacy code, and gradually over time consume legacy code

Assertion: TDD helps you write code faster

How to to sell refactoring technical debt to managment: explain how it will increase productivity

Joe: example of coverage report

Antony: showing video of coding work from pairwith.us

Videoing work is a great to to get feedback of what works, what doesn't.

Example of coding dojo: big team of developers, long dojo. Didn't work well

Better to run a small dojo, 15 minutes each, 2-4 devs. Easier to work of specific problems (focused)

Dojos sholdn't be done on existing codeSquirrel: we actually do dojos in a differnet language. Levels the playing field, helps junior devs become equal with senior devs

Without TDD, you write bugs faster :-)

With TDD, you become more confident with your code - you are more able to make bigger changes

TDD is faster - you get working production code much quicker

Encouraging people to run these practices: Screwfix did a competition where people self-organised into teams of about 3. Given a pariticular problem (eg game of life), all they were given was a very thin GUI framework, but no business rules. Every 2 weeks an afternoon was set aside for the competiting. Prizes if iTouch, etc for winners. Fun competition. Ran for about 6 months.

If people are always sprinting, they get burnted out. Avoid burnout by have 1 "rest" day, where dojos, open space conference, etc, give them

Google gives everyone 20% of their time (1 day a week) to let people work on their own projects

Regarding managemetn approval: it's better to seek forgiveness. Just go ahead and do this. If asked, state that you're training for required skills

Alternate view: you need the support of direct managemetn, otherwise you're screwed

Start doing the lunchtime dojos without approval, noone will necessarily ask what you're doing, if it's an issue How do you sustain TDD practice? New devs come in without experience, diluting skills

Also, under pressure, some poeple stop doing tdd.

Quote from Mary Poppendick: you can't drive fast if you're sitting in a traffic jam

TDD = code quality (code is well designed) = am I building the product right?

Acceptance Tests = application quality (code does right things) = am I building the right product?

What happens if you drop acceptance test: you will do the wrong thing quicker, or get to the right thing slower (Antony and Squirrel)