Path From Legacy Code To Unit Tests

From CitconWiki
Jump to: navigation, search

Llewellyn Falco

1. organise team to do 2 hours of mob programming a day (see and

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

 * 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