So you've decided to start doing testing and you've learned the basics -- how to write a test, how to go through the basic red/green/refactor cycle. Hooray! But now all the intermediate-level questions start to come up: what about different types of test? acceptance tests vs unit tests? How "purist" should I be about isolating my tests? When do I need to mock things, and what's the best way to do that? How do I reach the holy grail of TDD, which is to "listen to my tests" and let them drive the design of my code? Have no fear, answers here! We'll take a concrete example -- adding a new feature to a simple Django web app -- and use rigorous TDD to implement it, exploring our decisions and different testing options and philosophies along the way. We'll see a practical example of "double-loop" TDD featuring different types of tests, and also investigate the idea of "outside-in" TDD, in which the tests drive the development of your application from the UI layer downwards, rather than building bricks from the low-level upwards. We'll discuss when and why that might be a good idea, and how it fits with the MVC pattern. We'll have an extensive, hands-on investigation of the pros and cons of mocking, by writing the same feature once using mocks, and once without -- leading to a discussion of the pros and cons of mocking, and striving for test isolation in your unit tests. In doing so, we'll see if we can get a feeling for "listening to the tests", and the ideal that tests should help drive out good design in our code. All along, we'll be able to discuss why we're writing all these tests anyway, and how to get the best out of them in terms of * Avoiding defects * Writing clean, maintainable code * Achieving a productive workflow (*This tutorial is based on chapters 18 & 19 of my book, [Test-Driven Development with Python](http://www.obeythetestinggoat.com/)*)