Path From Legacy Code To Unit Tests

From CitconWiki
Revision as of 04:30, 12 September 2015 by Douglassquirrel (talk | contribs) (Created page with "Llewellyn Falco http://llewellynfalco.blogspot.co.uk 1. organise team to do 2 hours of mob programming a day (see mobprogramming.org) 2. get into habit of extracting methods...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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

1. organise team to do 2 hours of mob programming a day (see mobprogramming.org) 2. get into habit of extracting methods and renaming - that's all the mob does to start 7 stages of naming - Belshee

 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