After read the . Let me make a conclusion.
All the theory can be express by some Q&A
PART I------------------------------------------------------------
Q: How do you test your software?
A: Write an automated test.
Q: How should the running of tests affect one another:
A: Not at all.
Q: What should you test?
A: Before you begin, write a list all the tests you know you will have to write.
Q: When should you write you test?
A: Before you write the code that is to be tested.
Q: When should you write the asserts?
A: Try writing them first.
Q: What data do you use for test-first tests?
A: Use data that makes the tests easy to read and follow. (...)
Q: How do you represent the intent of the data?
A: Include expected and actual results in the test itself, and try to make their relationship apparent.
PART II-----------------------------------------------------------
Q: Which test should you pick next from the list?
A: Pick a test that will teach you something and that you are confident you can implement.
Q: Which test should you start with?
A: Start by testing a variant of an operation that doesn’t do anything.
Q: How do you spread the use of automated testing?
A: Ask for and give explanations in terms of tests.
Q: When do you write tests for externall produced software?
A: Before the first fime you are going to use a new facility in the package.
Q: How do you keep a technical discussion from straying off topic?
A: When a tangential idea arises, add a test to the list and go back to the topic.
Q: What do you do when a defect is reported?
A: Write the smallest possible test that fails and that, once run, will be repaired.
Q: What do you do when you are feeling lost?
A: Throw away the code and start over.
PART III(Detail)----------------------------------------------------
Q: How do you get a test case running that turns out to be too big?
A: Write a smaller test case that represents the broken part of the bigger test case.
Q: How do you test an object that relies on an expensive or complicated resource?
A: Create a fake version of the resource that answere constants.
Q: How do you test that one object communicates correctly with another?
A: Have the object under communicate with the test case instead of with the object it expect.
Q: How do you test that the sequence in which messages are called is correct?
A: Keep a log in a string, and append to the string when a message is called.
Q: How do you test error code that is unlikely to be invoked?
A: Invoke it anyway whith a special object that throws an exception instead of doing real work.
Q: How do you leave a programming session when you’re programming alone?
A: Leave the last test broken.
Q: How do you leave a programming session when you’re programming in a team?
A: Leave all of the tests running.
PART IV----------------------------------------------------------
Q: What is your first implementation once you have a broken test?
A: Return a constant.
Q: How do you most conservatively drive abstraction with tests?
A: Abstract only when you have two or more example.
Q: How do you implement simple operations?
A: Just implement them.
Q: How do you implement an operation that works with collections of objects?
A: Implement it without the collections first, then make it work with collections.
--------END--------
