Path From Legacy Code To Unit Tests

Llewellyn Falco http://llewellynfalco.blogspot.co.uk

1. organise team to do 2 hours of mob programming a day (see mobprogramming.org and https://en.m.wikipedia.org/wiki/Spaced_repetition)

2. get into habit of extracting methods and renaming - that's all the mob does to start

• 7 stages of naming - Belshee https://mobile.twitter.com/arlobelshee/status/636605852984545280/photo/1

 * nonsense
 * honest
 * honest & complete
 * does the right thing
 * intent
 * domain abstraction

(Note TDD starts at end - domain abstraction - and works backward!)

3. repeat until you find a functional component (input->deterministic processing->output)

4. create unit test using poking. Determine what the functional component does by passing in simple, valid, self-documenting values like 0, 1, "FirstName", "FlightNumber", or even null. Whatever it returns (if not an exception) is right - put it into a test and check it in

5. start measuring code coverage

6. so far we have been extracting functional components by accident - now we can start making simple changes, like extracting parameters previously read from a web request, that make components functional

7. larger modifications

8. mocking

9. modifictation to lighten the mocks

10. now we can actually do a little bit of test-first!

this takes a couple of months at 2 hours/day

Note mobbing works great to de-risk turnover and improve onboarding - a nine-year-old girl joined a mob and made a meaningful contribution as both driver and navigator

Llewelyn has not tried remote mobbing, but has been tried with one remote person (in an experienced mob) at Hunter

mobbing coaching tips https://github.com/isidore/AgileTechinicalCoaching/blob/master/Coaching%20CheatSheet.md