Monday, November 24, 2008

Constructing the testing pyramid

I like Mike Cohn's testing pyramid as a guideline for test allocation, and I've mentioned it to a couple of teams around here (for more, read Patrick Wilson-Welsh's blog and/or see his Agile 2008 presentation). Lately, on one team, we've been very earnest about writing Selenium tests for UATs, even doing some ATDD. But we're seeing what many have seen: Selenium tests are often (necessarily) long and slow, and occasionally brittle. I asked the team what our "testing pyramid" would look like, and it's something like this:

^^^^^^^^^^^^ (GUI/system)
^^^^^^^^^^ (functional)
^^^^^^^^^^^^^^^^^ (unit)
That is, the majority of our tests are at the unit level (that's good), but we are top-heavy with GUI tests. So with the help of the Ace team, we're moving toward more under-the-GUI integration tests using Webrat. Now we're looking more like:

^^^^^^^^^^^^ (GUI/system)
^^^^ (integration)
^^^^^^^^^^ (functional)
^^^^^^^^^^^^^^^^^ (unit)
The goal is to convert some of those Selenium (GUI/system) tests to Webrat (integration) and get our pyramid more in line (and help our team be more productive). There's still obviously need for the GUI-system tests, but we're just trying to be smarter about it. 

No comments: