This afternoon at Agile 2008 in Toronto, which has been a smashing good time, I led (with lots of help from Lisa Crispin, and then serendipitously from Brian Marick, J.B. Rainsberger, Dave LeBlanc, Matt VanVleet, and Declan Whelan) a presentation/workshop/micro-Open-Space session. I began with a premise from Mike Cohn: the idea of an ideal testing pyramid, or triangle, with three tiers:
What makes the triangle ideal is that you are spending most of your resources, and relying most, on the bottom-most tier of xUnit tests to do good things like protect you from defects and drive your design. That suite does the lion’s share of your regression protection, for example. And conversely, you are relying least, and expending least resources, on very slow, brittle, large, black-box, through-the-GUI, recorded kinds of tests as created by tools like Selenium IDE.
My notion is that this minimizes the Total Cost of Ownership (TCO) of your automated tests. Eventually.
It’s a long (3-hour!) conversation, but the gist, as presented, is that nearly no teams get to start with so well-formed a triangle, and in fact the triangle is most typically inverted for teams just starting down the agile path:
Given such a challenging starting point, you need three automated testing initiatives, one for each of the three kinds of tests (which I refer to metaphorically as brick, stick, and straw), to ensure that you end up with the triangle above. And this is hard, in large part because it is so hard to learn to produce really, really effective suites of unit/isolation/programmer/micro tests (as defined by folks like Michael Feathers, J.B. Rainsberger, Mike Hill, Bob Martin, etc). And the triangle-flipping is hard also because we are talking about culture change, and resistance to it. Well, of course, there are lots of other reasons why it’s hard. It’s hard.
In the presentation, we explored, together, lots of subcategories of this automated-testing-triangle-flipping challenge. To my mind, there were lots of aha moments and unexpected conclusions and good ideas.
So, I’ll blog more on the details later. In the meantime, as promised to several people, here is a link to a PDF version of the presentation. I have had trouble uploading the Keynote version, and so abandoned that. PDF is likely best in any case.
Thanks again to all who attended, and all who helped me prepare and present. It was a blast.
My next goal for this material is to extend it into an experiential, inspirational, 2-day training course that allows cross-disciplinary teams to experience the nasty cruddy inverted testing triangle on day one, and the lovely, right-side-up triangle on day two. More later. Now, at 2:00 AM, off to bed with this agilista.


Glad to hear the presentation went off without a hitch, and hopefully not too much heckling from Brian Marick…
All so true. Hopefully it opens a few more eyes at certain levels of the corporate pyramide and amongst those who call themselves developers.
What was that analogy again about “questions that haven’t been asked”?
Jeremy: Paul Tillich’s Fatal Pedagogical Error: “Throwing answers like stones at the heads of those who have not yet asked the questions.”
[...] This post was Twitted by csterwa – Real-url.org [...]
Agile Testing Pyramid…
Agile testing relies on a solid foundation of automated unit tests. These can be run with each new build to regressiontest the system. Performing a complete,……
[...] 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 [...]
I looked at the Mike Cohn’s ideal Triangle and tried to do a health check for our web application
1. We have a good foundation of Unit test.
2. We also have decent coverage using Selenium for UI tests
3. We are MISSING Integration testing or API testing OOPS…!!
4. We do few manual test.
For past one week my colleagues and I started looking into various ideas to API testing. Soon we realized that none of us know how to do it. We all have our ideas but after one week of thinking and work we still don’t understand.*sigh*. I picked up a simple use case and attempted it. I have drawn various components below
Application is built on WebSphere Portal.
————–
UI (JSP + JSF)
————-
|
V
———-
Controller (Plain java)
———-
|
V
———–
Business Manager (Plain Java)
————
|
V
———————————————————
DAO (uses JNDI to locate various services configured on Websphere application Server
——————————————————– | | V V
Use Websphere Uses Websphere PUMA
DB connection component to do CRUD
pool operation on LDAP
——————————————————–
Story I tried to test is
*********************************************************
Feature: SignON – Authorization
As a business owner do not want users with disabled status to access the system. Instead, appropriate error
code and audit logs should be done.
Scenario Outline: Check invalid status
Given User with userid “” have authenticated successfully
When User account is disabled for “”
Then return error should be “”
and log enttry should be “”
and user status should remain disabled
Examples:
|userId|disabledReason|errorCode|
|uid12345|kpl|SO:X9|User account is locked. Login attempt made|
*********************************************************
I decided to test an API from controller layer using Cumber. It was very easy to configure it up and running using Maven. Wow!! I thought, I can run my API testing with my build. I was making good progress but not for long. I got stuck at the DAO layer. In this layer we do JNDI lookup for DB connect pool and User management service. Since tests will run outside the websphere container JVM, of course these services aren’t available to me. This means that I need to mock my DAO’s. But If I mock the DAO’s then what is the difference between my Unit Test and Integration test. In my integration test, I want to test if my audit log was created in DB. My integration test should read audit table and confirm this. Similarly, I need to validate users account status is not changed in LDAP.
What is your suggestion in this kind of scenario? Shall we use mock, (if yes, then how different is it from Unit test). Also writing mock for these kind of services won’t be trivial. They will be time consuming. Because I need to provide similar behavior to enable my Mock’s to add records in DB and update/read LDAP.
Another thought that come to my mind is to use UI to do all the testing. Write hooks in selenium tests. In a selenium test read DB and LDAP and confirm if things were appended correctly. But then I think, isn’t selenium only for testing use experience on glass and not for API kind of testing. By doing so, I am violating Cohan’s triangle.
I will really appreciate your thoughts on this test case. Please enlighten me.
Kind Regards,
clarification on DAO layer
———————————————————————————————
DAO (uses JNDI to locate various services configured on Websphere application Server
——————————————————–————————————
| |
V V
Use Websphere Uses Websphere PUMA
DB connection component to do CRUD
pool operation on LDAP
——————————————————–———————————