.KnowHowTo.EvolveStorytestsForWeb

.KnowHowTo.EvolveStorytestsForWeb

Part 3: Rick Mugridge, 13 May 2011

A defined action in FitLibrary allows us to:
We look at applying this to the storytests for a web application, where the implementation-level storytests are written using SpiderFixture from FitLibraryWeb.

Then we look at how to best organise our defined actions.

The general principles here are also relevant to users of FitSharp and Slim and other test automation tools.

1. Use a Higher-Level Language

Rather than talking about implementation-specific details, we can use the language of the business. Defined actions provide the mapping from one to the other.

For example, in order to test a web application, we have a storytest that specifies business flow and contains the following action:

click//a[@id='showInventory']

But this is very implementation-specific:
We can improve that by replacing the above table with the following:

show inventory

Now we need to define the mapping from the business level to the implementation level with a defined action (usually added to a separate page):

show inventory

click//a[@id='showInventory']


This consists of two parts:
Now when we use the defined action we get several benefits:

2. Avoid Repetition

Rather than repeating a large table or a sequence of tables, we can introduce a simpler table that stands for the whole.

For example, our web application has a mechanism for paying by cash:

with//input[@id='cashAmount']add text49.20

click//a[@id='pay']

element//div[@id='error']does not exist

click//a[@id='completeTransaction']

element//div[@id='error']does not exist

We use that in lots of storytests, but with different amounts. We can improve that with a defined action:

pay cash $cash

with//input[@id='cashAmount']add text@{cash}

click//a[@id='pay']

element//div[@id='error']does not exist

click//a[@id='completeTransaction']

element//div[@id='error']does not exist


Again, this consists of two parts:
So now we can use that in our storytests. Eg:

pay cash $49.20

This shrinks the storytest considerably:

3. Organising Defined Actions


When starting with defined actions, the simplest approach is to put them in a page at the top of your project suite, called DefinedActions. Then they can be loaded for testing with the following action:

define actions at.DefinedActions

Include this in the SuiteSetUp page, so they will then be loaded once at the start of testing a suite or a single test page.

More than one defined action can be placed in a single page. They are separated by a horizontal line with "----", as shown above.

It can make sense to put short, related defined actions together in a single page. But if there are too many, it makes it difficult to find them.

As the number of defined actions grow, they need to be organised. Instead of putting all of them in a single page, they can be defined in pages underneath DefinedActions, and they will be automatically loaded. These can then be organised around the domain and implementation levels.

4. Use Language Layers

With a large suite of storytests for a web-based application, the number of defined actions can grow considerably. What's the best way of organising the storytests and defined actions?

A good approach is to organise them around language layers:

Business rules and constraints
Business processes
persona-based example data
Flow based on web page traversal
Main pieces of functionality on a web page (forms, etc)
Elements on the page (where they're used more than once in the layer above)

Storytests include the first two layers, with business processes encoded in defined actions for the top-most layer. Each of these can in turn be organised around the business (eg, all the rules related to payments) or implementation domain (eg, all the defined actions for a particular page are kept together).

The third layer is a good place to define pre-canned example data that can be used in several storytests. Eg:
This approach also applies if there are several types of implementation level. Eg:

Business rules and constraints
Business processes
persona-based example data
Flow based on: Web page traversal... REST... messaging & email
Web pagecalling/calledroutingDB access
Page xml/json detailsmessage formatsDB tables

5. Questions

How do you organise your defined actions (or scenarios or procedures)?

Does that work well for you?

Do you make use of persona examples?

They can mean that a lot of inessential information can be left out of storytests.