Path From Legacy Code To Unit Tests - Revision history

Douglassquirrel at 12:01, 12 September 2015

2015-09-12T12:01:00Z

Douglassquirrel at 11:55, 12 September 2015

2015-09-12T11:55:08Z

Douglassquirrel at 11:42, 12 September 2015

2015-09-12T11:42:47Z

Douglassquirrel at 11:38, 12 September 2015

2015-09-12T11:38:45Z

Douglassquirrel at 11:36, 12 September 2015

2015-09-12T11:36:32Z

Douglassquirrel: 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..."

2015-09-12T11:30:26Z

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..."

New page

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

← Older revision		Revision as of 12:01, 12 September 2015
Line 36:		Line 36:

	Llewelyn has not tried remote mobbing, but has been tried with one remote person (in an experienced mob) at Hunter		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

← Older revision		Revision as of 11:55, 12 September 2015
Line 32:		Line 32:

	this takes a couple of months at 2 hours/day		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

@@ Line 5: / Line 5: @@
 . get into habit of extracting methods and renaming - that's all the mob does to start
-* 7 stages of naming - Belshee
+* 7 stages of naming - Belshee https://mobile.twitter.com/arlobelshee/status/636605852984545280/photo/1
    * nonsense
    * honest

@@ Line 1: / Line 1: @@
 Llewellyn Falco http://llewellynfalco.blogspot.co.uk
-. organise team to do 2 hours of mob programming a day (see mobprogramming.org)
+. organise team to do 2 hours of mob programming a day (see mobprogramming.org and https://en.m.wikipedia.org/wiki/Spaced_repetition)
 . get into habit of extracting methods and renaming - that's all the mob does to start

@@ Line 2: / Line 2: @@
 . organise team to do 2 hours of mob programming a day (see mobprogramming.org)
 . get into habit of extracting methods and renaming - that's all the mob does to start
 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
 (Note TDD starts at end - domain abstraction - and works backward!)
 . repeat until you find a functional component (input->deterministic processing->output)
 . 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
 . start measuring code coverage
 . 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
 . larger modifications
 . mocking
 . modifictation to lighten the mocks
 . now we can actually do a little bit of test-first!
 this takes a couple of months at 2 hours/day