TDD in the Web with Python and Django
- 1. TDD in the Web with Python XP Conference 2011 Carlos Blé www.carlosble.com @carlosble
- 2. The Architecture Ruby on Rails, Django , Monorail, ASP.Net MVC, Spring MVC, Play Framework, Symphony, Zend Framework...
- 3. We like to think like this
- 4. Separate concerns Controller : Deals with the browser . Get the input, make some calls and return the output . It should be as simple as possible. The less it knows about the domain, the better. View : Renders UI. Doesn't know the domain at all!!! Domain : Deals with the user . Business requirements. Wouldn't be cool if we can exercise the domain using ”end-to-end” tests?
- 5. Test-driving Inside-out (bottom-up) So we can test-drive the domain and invoke it from the controller after all, like this: Now we can write an integration test for this controller... but integration tests are painful!
- 6. Is not that clean always :-(
- 7. When the controller needs to know Validation rules
- 8. How to parse complex data (forms)
- 9. Which UI to render for a given scenario We end up with a mess :-(
- 10. Test-driving Outside-in (top-down) Integration tests are a scam. Let's go ” unit” We don't use Django's TestCase, but unittest's
- 11. Replacing with test doubles
- 12. Replace conditional with polymorphism We can move conditionals from views to controllers
- 13. Replace conditional with polymorphism Django templates inheritance is so cool!!!
- 14. Conclusions End-to-end tests for the domain, are cheaper excluding web concerns (controllers, UIs)
- 15. Selenium (or Webdriver) tests are too fragile
- 16. Test-driving controllers give us fast feedback
- 17. So we recommend: Unit test the controllers (test-first)
- 18. Unit test the domain (test-first)
- 19. Write integration tests for DB access, etc
- 20. Write end-to-end tests for the domain We don't use Django's TestCase, but unittest's