TDD in the Web with Python and Django

TDD in the Web with Python and Django

• 1.
  TDD inthe Web with Python XP Conference 2011 Carlos Blé www.carlosble.com @carlosble
• 2.
  The Architecture Rubyon Rails, Django , Monorail, ASP.Net MVC, Spring MVC, Play Framework, Symphony, Zend Framework...
• 3.
  We like tothink 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 thatclean always :-(
• 7.
  When the controller needs to know Validation rules
• 8.
  How to parsecomplex data (forms)
• 9.
  Which UI torender 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 testdoubles
• 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 testsfor the domain, are cheaper excluding web concerns (controllers, UIs)
• 15.
  Selenium (or Webdriver)tests are too fragile
• 16.
  Test-driving controllers giveus fast feedback
• 17.
  So we recommend:Unit test the controllers (test-first)
• 18.
  Unit test thedomain (test-first)
• 19.
  Write integration testsfor DB access, etc
• 20.
  Write end-to-end testsfor the domain We don't use Django's TestCase, but unittest's