prefaceprerequisites and assumptionscompanion videoacknowledgmentspart i. the basics of tdd and django1. getting django set up using a functional test  obey the testing goat！ do nothing until you have a test  getting django up and running  starting a git repository2. extending our functional test using the unittest module  using a functional test to scope out a minimum viable app  the python standard library's unittest module  implicit waits  commit3. testing a simple home page with unit tests  our first django app, and our first unit test  unit tests, and how they differ from functional tests  unit testing in django  django's mvc, urls, and view functions  at last！ we actually write some application code！  urls.py  unit testing a view    the unit-test/code cycle4. what are we doing with all these tests？  programming is like pulling a bucket of water up from a well  using selenium to test user interactions  the "don't test constants" rule, and templates to the rescue    refactoring to use a template  on refactoring  a little more of our front page  recap: the tdd processs. saving user input  wiring up our form to send a post request  processing a post request on the server  passing python variables to be rendered in the template  three strikes and refactor  the django orm and our first model    our first database migration    the test gets surprisingly far    a new field means a new migration  saving the post to the database  redirect after a post    better unit testing practice: each test should test one thing  rendering items in the template  creating our production database with migrate6. getting to the minimum viable site  ensuring test isolation in functional tests    running lust the unit tests  small design when necessary    yagni！    rest  implementing the new design using tdd  iterating towards the new design  testing views, templates, and urls together with the django test client    a new test class    a new url    a new view function    a separate template for viewing lists  another url and view for adding list items    a test class for new list creation    a url and view for new list creation    removing now-redundant code and tests    pointing our forms at the new url  adjusting our models    a foreign key relationship    adjusting the rest of the world to our new models  each list should have its own url    capturing parameters from urls    adjusting new_list to the new world  one more view to handle adding items to an existing list    beware of greedy regular expressions！    the last new url    the last new view    but how to use that url in the form？  a final refactor using url includespart ii.  web development sine qua nons  7. prettification: layout and styling, and what to test about it  8. testing deployment using a staging site.  9. automating deployment with fabric  10. input validation and test organisation  11. a simple form  12. more advanced forms  13. dipping our toes, very tentatively, into javascript  14. deploying our new codepart iii.  more advanced topics  15. user authentication, integrating third-party plugins, and mocking with javascript.  16. server-side authentication and mocking in python  17. test fixtures, logging, and server-side debugging  18. finishing "my lists": outside-in tdd  19. test isolation, and "listening to your tests".  20. continuous inteoration （ci）  21. the token social bit, the page pattern, and an exercise for the reader  22. fast tests, slow tests, and hot lava..obey the testing goat！a. pythonanywhereb. django class-based viewsc. provisioning with ansibled. testing database migrationse. behaviour-driven development （bdd）f. cheat sheetg. what to do nexth. bibliographyindex