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