Blogging Pubbitch

It's time to talk testing. Specifically, it's time to talk about a strategy for testing java web apps. Let's take it from the top, from the level of the person writing the initial tests, down to the place where the developers live. Let's not rush ourselves; we've got a while so more than one part is okay.

At the top, there's one of two types of acceptance test. The initial type is a normal looking JUnit test, with several "testFoo" methods. The difference is that these tests are written in the language of the business:

public void testNavigationLinksShouldMaintainTheQueryUsedToGenerateTheResultList() throws Exception {
        loginAs("Barry White");
        selectDJ("Dave Lee Travis");
        searchForMyRecordsOwnedByTheDJStartingWith("t");
        countNumberOfPagesOfResults();
        gotoNextPage();
        countNumberOfPagesOfResultsAgain();
        verifyThatTheNumberOfPagesSeenWasTheSameBothTimes();
}

Even my mum could read that. These are written by the QAs using an IDE that generates stub methods so that the thing compiles cleanly. The cleanly compiling tests are then checked in to our source control system and run as part of our normal build.

But wait! Surely those tests won't pass, and will therefore cause the build to fail horribly? Not if you use a TestSuite that supports allowing a test to fail until the first time it's passed, and then never allows it to fail again. You could even produce a nice summary page in your Continuous Integration environment to allow the business to track the progress of the project.

The other type of test that we run is a FIT test. These can work really well, and they can also bring an entire project to its knees; you just need to know what's good and what's not. What's not include "clicky" tests, that interact directly and extensively with the UI. These swiftly become very brittle and require a lot of TLC to work properly as the GUI changes. What works well? I'm still exploring, but something nice and high level, that deals with the intent is clearly the way forwards. Something like

| login as | Barry White |

rather than

| goto |  home url |
| click | button with id | login |
| select element | username |
| enter | Barry White |
| select element | password |
| enter | secret password |

One of those is clearly a suboptimal way of doing things. Guess which!

So, we've written our high level acceptance tests. What next? You'll just have to wait....