Functional tests should help you build an application with the right functionality, and guarantee you never accidentally break it. Unit tests should help you to write code that’s clean and bug free.引自第123页
We can start to settle into the TDD unit-test/code cycle now:
1. In the terminal, run the unit tests and see how they fail.
2. In the editor, make a minimal code change to address the current test failure.
And repeat!引自第31页
Kent Beck (who basically invented TDD) uses the metaphor of lifting a bucket of water out of a well with a rope: when the well isn’t too deep, and the bucket isn’t very full, it’s easy. And even lifting a full bucket is pretty easy at first. But after a while, you’re going to get tired. TDD is like having a ratchet that lets you save your progress, take a break, and make sure you never slip backwards. That way you don’t have to be smart all the time.
...
TDD is a discipline, and that means it’s not something that comes naturally; because many of the payoffs aren’t immediate but only come in the longer term, you have to force yourself to do it in the moment. That’s what the image of the Testing Goat is supposed to illustrate—you need to be a bit bloody-minded about it.引自第36页
Good unit testing practice says that each test should only test one thing. The reason is that it makes it easier to track down bugs. Having multiple assertions in a test means that, if the test fails on an early assertion, you don’t know what the status of the later assertions is.引自第68页
JSON TEST FIXTRES CONSIDERED HARMFUL
They're a nightmare to maintain when your model changes. Instead, if you can, load data directly using the Django ORM, or look into a tool like factory_boy.引自 Chapter 17. Test Fixtures, Logging and Server-Side Debugging
Outside-In isn't a silver bullet. It encourages us to focus on things that are immediately visible to the user, but it won't automatically remind us to write other cirtical tests that are less user-visible, things like security for example. You'll need to remeber them yourself.引自 Chapter 18. Finishing "My Lists": Outside-In TDD
Proceeding to work on lower levels while you're not sure that the higher levels are really finished or not is a risky strategy.
Two common mistakes when using mock side-effects are: assigning the side effect too late, i.e. after you call the function under test, and forgetting to check that the side-effect function was actually called.
HIDING ORM CODE BEHIND HELPER METHODS
...some people like to try and minimise the amount of ORM code in the application -- particularly removing it from the views and forms layer.
One reason is that it makes it much easier to test those layers. But another is that it foces us to build helper functions that express our domain logic more clearly.
Use in-memory (unsaved) model objects in your tests whenever you can, ite makes your tests faster.
When doing outside-in TDD with isolated tests, you need to keep track of each test's implicit assumptions about the contract which the next layer should implemented, and remember to test each of those in turn later.引自 Chapter 19. Test isolation, and "Listening to Your Tests"
