Helmkamp on Story-Driven Development

Gaffo noted this very good talk -- "Story Driven Development" -- by "the guy who runs webrat" (aka Bryan Helmkamp):

It really picks up about 25 minutes in for us, but the first 25 minutes are interesting because they cover Rspec and story runner (the precursor to cucumber). He's talking about a lot of the things we're currently running into and I think it will help facilitate later discussions.

Good stuff; I second Mike's commendation.

Testing Pyramid, part 2

I went ahead and grabbed the actual test numbers from the build(s) -- simply the total number of assertions in each of the test levels (unit, functional, integration and UI) -- and generated a chart in Excel:

I posted it in our war room; we'll see what kind of conversation it sparks. It looks like we need to continue moving toward increasing the ratio of webrat (integration) tests to Selenium (UI) tests, as well as upping our base level of units. Using the actual data also corrected my anecdotal assumption that we had a lot more unit tests than we do (see my sketch in my previous post).

UPDATE: I ran the numbers for another team. Here's their chart:
This team has some UI tests written in Watir, but they don't run them (so they're useless). All of their integration tests are Webrat; apparently, these can be run as Selenium tests, but the team isn't doing that (yet). This team has the fundamentals down well -- more unit tests than functional, more functional than integration. We'll see how they expand the upper levels of their triangle in the coming weeks.

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. 

Aysnchrony Mentioned In Local Blog

A local blog titled "Downtown St. Louis Business" does a fantastic job posting the latest news, rumors, and rumblings of local area corporations.

Brian, the site's primary author, posted a column earlier this week that summarized local businesses that have sadly relocated their headquarters from downtown St. Louis, to other areas of the metro area.

On a much brighter note, Brian posted a column today that notes local businesses that have pursued the opposite path - moving their business *into* the downtown perimeter. Although it isn't exactly "news" - since Asynchrony relocated from Earth City in April '08 - it's nice to see our business recognized as one of the local corporations contributing to the growth of downtown St. Louis.

Here here.

ENTER key press in Selenium

Mike Gage needed to simulate an ENTER key press in Selenium to call a submit. Erstwhile Asynchronite Ryan Tyer provided some helpful feedback via Twitter (we're gonna miss him!):

In selenium, there is a submit function. This submits the form without using a submit button, same as an enter key press. [And in a followup:] Further, you should be able to simulate an enter key press with selenium...in rc (java) selenium.keyDown(id, "\\13");

Mike specifically wanted to make sure that the ENTER did something, which meant that he didn't want to use the submit function in Selenium. Here's what worked for him, using Ryan's approach (only with KeyPress) -- in Firefox, at least:

[Test]
public void EnterKeyPressedOnTextAreaTriggersSubmit()
{
selenium.Open("/");
selenium.WaitForPageToLoad(DEFAULT_PAGE_TIMEOUT);
selenium.Type("quicksearchtextcriteria", "text");
selenium.KeyPress("quicksearchtextcriteria", "13");
selenium.WaitForPageToLoad(DEFAULT_PAGE_TIMEOUT);

Assert.IsTrue(selenium.IsTextPresent("We could not find an exact match for your Quick Search entry"));
}

Tip: A Visible Approach to Sizing Stories

Brian sent me an email that had this interesting tip from another Brian, Brian Bozzuto:

Next time you are sizing a large number of stories - especially when beginning a new project - consider using a visual method. This exercise is best done with a long table. Begin with an average size story card and place it in the center of the table. Take the next story and place it either above or below the first story depending on its size. The team should, one at a time, place stories on the table relative to the size of those already laid out. Rather than trying to define an absolute size, the team will sort stories based on their approximate size.

This exercise forces people to think in relative terms instead of absolute estimates. Once all the stories have been placed in order, the team takes a set of planning poker cards and inserts each card along the spectrum of stories to identify the transition from one size to the next larger one. For example, those stories on the simple end of the sizing spectrum will start at "1", and the team will place the "3" card at the point where the first story is that should be sized as 3 instead of 1. The team is done once they have ordered every story on the table and grouped them into one of the story sizes.

This visual exercise is most useful when a team has a hard time moving from the high precision exercise of estimating to the relative exercise of sizing. It is also useful when there are a large number of stories to be sized, as most teams will move through the sizing much faster than in traditional planning poker. However, it does allow each individual to provide an unbiased opinion, and moderators should be sensitive to the fact that soft spoken team members may have a harder time offering input.

If anyone tries this, let us know.