读书笔记《测试驱动开发》

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