<> Summary

<<TDD by example>> notes
Why TDD?*****
1. Automated test
---Game in TWI
---stress->高->testing少->errors多->stress高
---stress->高->自动testing多->errors少->stress低
2. For design, we use test to drive the design instead of design first and then write the test.
---Think from the consumer point of view. Think from the interface. Avoid over design.(Consumer aspect)
---Your designs must consist of many highly cohesive, loosely coupled components, just to make testing easy. (Highly cohesive, loosely coupled)
3. Continuous feed back
---A working test is a step closer to having every thing working.
 
1. Two simple rules of TDD.
---Write a failing automated test before you write any code.
---Remove duplication.
The two rules imply thean order to the tasks of programming.
Red/Green/Refactor

2. Manage a todo list during TDD. How to do the tasking?
---From the business value point or the implementation task point?*****

3. We have a failing test and we want it to go green as quickly as possible, even by returning the expected result directly.
Why so hurry to green? What if I forget that green is a fake one?*****
We use triangulation to avoid it. What's more, we only work on one place, so we won't fake in more than 2 places.
Triangulation sometimes feels funny, so it is only used when we are unsure how to refactor.

(4. The Money value object.)

5. Never interrupt an interruption.

6. There is no right step size in TDD. TDD is a steering process--a little this way, a little that way.
---Do we need to design in advance? Sometimes we can keep the Todo list as a roadmap.*****

(7. Any time you are checking classes explicitly, you should be using polymorphism instead.)
if(animal instanceof Foo)...

8. When the todo list becomes empty, it is the time to review the design.

9. TDD followed religiously should result in 100% statement coverage.

10. Regression Test. When a defect is reported, write the smallest possible test that fails, and that once it runs, the defect will be repaired. Think about how you could have know to write the test in the first place.

11. Cases:*****
Uri format, empty, exist. NotEmpty.

Patterns
Test-Driven Development Patterns
---Test n. Use automated test to lower the stress
---Isolated Test
---Test List (I understand it as a todo list?)
---Test First
---Assert First
------Where should you start building a system? With stories you want to be able to tell about the finished system.
------Where should you start writing a bit of functionality? With the tests you want to pass with the finished code.
------Where should you start writing a test? With the asserts that will pass when it is done.
---Test Data
---Evident Data

Red Bar Patterns
---One Step Test. Which test should you pick next from the list? Pick a test that will teach you something and that you are confident you can implement.
---Starter Test. Start by testing a variant of an operation that doesn't do anything, because we need to solve the problem of "where does it belong?" first and a "realistic" test has a bunch of problems to solve.
One Step Test applies after the starter test.
---Explanation Test. Ask for and give explanations in terms of tests. Specification by example???
---Learning Test. Tests to assert some functions of the existing systems.
---Another Test. New ideas are written down on the list to avoid distraction from current work.
---Regression Test. When a defect is reported, write the smallest possible test that fails, and that once it runs, the defect will be repaired. Think about how you could have know to write the test in the first place.
---Break
---Do Over. Throw away the code and start over if you are feeling lost.
---Cheap desk, Nice Chair.

Testing Patterns
---Child test. A test too big. Write smaller one represents the broken part.
---Mock Object
---Self Shunt. Communicate with the test case
---Log string
---Crash Test Dummy
---Broken test. Keep a broken test when working alone.
---Clean check in. Team work, clean check in.

Green Bar Patterns
---Fake it. To get it quickly green, return a constant as the fake.
---Triangulate
---Obvious implementation.
---One to many

XUnit Patterns
---Assertion
---Fixture
---External fixture
---Test Method
---Exception Test
---AllTests