Alex Yakyma: Acceptance Testing Pattern: Detachable GUI

By Alex Yakyma

One of the problems that many software teams have is with acceptance testing a system thru GUI. Testing logic thru GUI is very fragile. Even though UI testing tools are continuously evolving, the nature of UI (as Human-to-System interface) will be constantly a hard problem with respect to test automation.

To better understand the pattern that we will introduce below, let us start with the example. Let's consider widely known and used open source project - 7z - archiving program. Imagine how will you test "Add to archive" function thru GUI. Here's a screenshot for that if you're using 7z version with rich GUI:

Testing this function thru UI will be hard: it requires to test it on few different screens accessing multiple different controls. It is hard and changes in UI (like layout, UI controls attributes etc) may instantaneously make all tests fail and then (most importantly) take a lot of time to fix them.

Now let's consider command line version:

It is quite easy to automate this with help of any scripting language that can run applications and access disk.

This illustrates very simple idea:

There's much more value in acceptance testing the system logic thru really convenient interface rather than aiming too high (testing thru GUI) but end up with impractical unsustainable testing strategy.

I've seen a number of good agile teams that struggled hard to test logic thru GUI and were constantly failing (even though some of them were trying to invent some convenient macro-wrappers around GUI testing frameworks like Selenium and so on). But when they started from different angle - testing business logic directly, it immediately became a powerful agile practice maintained by whole team. Simplest example is when team simply starts developing Acceptance Tests with JUnit, but using only "highest-level interfaces". There's whole bunch of tools though that are suited for this purpose much better (JBehave, Cucumber, FIT etc).

It is vital to have convenient, easy-to-use acceptance testing strategy rather then something that will be adequate testing method, because:

Convenient strategy will be used by both developers and testers, will become their "communication and collaboration protocol"
Convenient strategy will serve a great requirements discovery tool and will be used by team and their PO
Convenient strategy will help team ensure high coverage
Convenient strategy is vital for concurrent testing and even more so for test-driven techniques

Direct testing of system logic allows for all these great benefits.

It's worth mentioning that teams should strive to design for this kind of testability. If your GUI and Logic look like spaghetti, you will not be very successful with any testing apparently. UI needs to be "logically detachable" from the logic so you can test it safely. If it's not so, start gradually detaching it (in story-by-story fashion).

Highly coupled (read: messy) GUI and Logic...