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