TDD in the Web with Python

XP Conference 2011

Carlos Blwww.carlosble.com@carlosble

The Architecture

Ruby on Rails, Django, Monorail, ASP.Net MVC, Spring MVC, Play Framework, Symphony, Zend Framework...

We like to think like this

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?

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!

Is not that clean always :-(

When the controller needs to know

Validation rules

How to parse complex data (forms)

Which UI to render for a given scenario

We end up with a mess :-(

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

Replacing with test doubles

Replace conditional with polymorphism

We can move conditionals from views to controllers

Replace conditional with polymorphism

Django templates inheritance is so cool!!!

Conclusions

End-to-end tests for the domain, are cheaper excluding web concerns (controllers, UIs)

Selenium (or Webdriver) tests are too fragile

Test-driving controllers give us fast feedback

So we recommend:Unit test the controllers (test-first)

Unit test the domain (test-first)

Write integration tests for DB access, etc

Write end-to-end tests for the domain

We don't use Django's TestCase, but unittest's

Muokkaa otsikon tekstimuotoa napsauttamalla

Muokkaa jsennyksen tekstimuotoa napsauttamallaToinen jsennystasoKolmas jsennystasoNeljs jsennystasoViides jsennystasoKuudes jsennystasoSeitsems jsennystasoKahdeksas jsennystasoYhdekss jsennystaso