13 habits to good TDD programming "refactored to" 12 habits to good TDD programming

gistfile1.txt

1) Write a failing test
2) Write the simplest code to pass the test
3) Refactor to remove duplications
4) Write the assertion first and work backwards
5) See the test fail
6) Write meaningful tests
7) Triangulate
8) Keep your test and model code separate
9) Isolate your tests
10) Organise your tests to reflect model code
11) Maintain your tests
12) Test should test one thing only
13) Don't refactor with failing test(s)

- Jason Gorman - one of our our TDD icons!


-- First iteration of refactoring -- 
12 habits to good TDD programming: 
 1) Write the assertion first and work backwards 
 2) Test should test one thing only 
 3) See the test fail 
 4) Write the simplest code to pass the test 
 5) Refactor to remove duplications 
 6) Don’t refactor with failing test(s) 
 7) Write meaningful tests 
 8) Triangulate
 9) Keep your test and model code separate (except when practising TDD-as-if-you-meant-it) 
10) Isolate your tests 
11) Organise your tests to reflect model code 
12) Maintain your tests


-- Next iteration of refactoring -- 

12 habits to good TDD programming:
(preparations)
- Give your test a meaningful name (behaviour / goal-oriented)
- Test should test one thing only (one logical assertion) 
- Your tests should reflect your domain (e.g. behaviours)
- Write the assertion first and work backwards 

(actions)
- See the test fail
- Write the simplest code to pass the test
- Refactor to remove smells (eg. duplications) & "maximise" clarity
- Don't refactor with failing test(s)
- Triangulate
- Keep your test and model (domain) code separate 
  (except when practising TDD-as-if-you-meant-it)
- Isolate your tests (de-coupled from other tests)
- Maintain your tests (just like model / domain code)

See for details http://neomatrix369.wordpress.com/2013/09/27/socrates-uk-2013-my-experiences/