Difference between revisions of "Path From Legacy Code To Unit Tests"
(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...") |
|||
| Line 2: | Line 2: | ||
1. organise team to do 2 hours of mob programming a day (see mobprogramming.org) | 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 | 2. get into habit of extracting methods and renaming - that's all the mob does to start | ||
| − | 7 stages of naming - Belshee | + | |
| − | nonsense | + | * 7 stages of naming - Belshee |
| − | honest | + | * nonsense |
| − | honest & complete | + | * honest |
| − | does the right thing | + | * honest & complete |
| − | intent | + | * does the right thing |
| − | domain abstraction | + | * intent |
| + | * domain abstraction | ||
| + | |||
(Note TDD starts at end - domain abstraction - and works backward!) | (Note TDD starts at end - domain abstraction - and works backward!) | ||
| + | |||
3. repeat until you find a functional component (input->deterministic processing->output) | 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 | 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 | 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 | 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 | 7. larger modifications | ||
| + | |||
8. mocking | 8. mocking | ||
| + | |||
9. modifictation to lighten the mocks | 9. modifictation to lighten the mocks | ||
| + | |||
10. now we can actually do a little bit of test-first! | 10. now we can actually do a little bit of test-first! | ||
this takes a couple of months at 2 hours/day | this takes a couple of months at 2 hours/day | ||
Revision as of 04:36, 12 September 2015
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
