Agile Testing with Lisa Crispin

!define NavigateToAddChangeRatingScale (${NavigateToRatingScale}
!|SWAT|
|StimulateElement|Expression|

innerHTML:Overall Review|onclick|A|
)

!define InputNumberOfLevels (
!|SWAT|
|SetElementAttribute|

Expression|Id:txtLevelNums|value |${NumberOfLevels}|INPUT|
|StimulateElement   |Expression|Id:txtLevelNums|onchange|INPUT|
)

These are ‘macros’ defined as variables. Cool, huh? Notice that the second one, NavigateToAddChangeRatingScale, uses the first one, NavigateToRatingScale.

Here are examples of how we used these in test pages. First we include the page at the top of the test page;

!*> includes
!include -c <SuiteBookworms.HelperMacro.

RatingScales
*!

Then we can use whichever of the macros within RatingScales that we need at any time.

Navigate to add/change rating scale page
${

NavigateToAddChangeRatingScale}

When you view the test page in the browser, you see:

It’s easy to understand what the test is doing, but we only have to maintain those steps on one page.

Here’s an example of setting the number of levels in a rating scale:

!define NumberOfLevels {5}
${InputNumberOfLevels}

In the browser view, this looks like:

We have the kind of macros I’ve always been used to as well for example, a login macro:

{HomeUr}!*> login to $ with ${UserName} and ${Password}
!|SWAT|
|NavigateBrowser|${HomeUr\l}|
|SetElementAttribute|Id|ctl00_

Content_Login1_UserName|value|${UserName}|INPUT|
|SetElementAttribute|Id|ctl00_Content_Login1_Password|value|${\Password}|INPUT|
|StimulateElement|Id|ctl00_Content_Login1_LoginButton|onclick|INPUT|
*!

which are included in a test in the way to which I am accustomed:

!define UserName {hobbest}
!include <SuiteBookworms.HelperMacro.LoginMacro

I can’t articulate why I like the first, different approach, using variables to hold the macros, better than the way I’ve done it for years. It seems more streamlined to me, while retaining the ease of maintenance and understandability. Say sometimes you want to navigate to Page A, and other times you need to get to Page 2 which requires first going to Page A. If you’re including a bunch of one-line macros – one to navigate to Page A, one to navigate to Page 2 – your test gets real clunky looking.

Something Really Slick

Maykel, J.P. and Eddy used a similar technique so that a test could iterate through the same steps with different inputs each time. A variable is defined with a SWAT FitNesse table as its contents, including both a variable for the input value and a variable for the assert. Then it’s quick and easy to have multiple test cases using the same table. It took me a little while wo work out what they’re doing, but I love it.

!define AssertValidInputNumberOfLevels (
${InputNumberOfLevels}
!|SWAT|
|@AssertElement\${Exists}|

Expression|innerHtml:Invalid numeric value. Value should be a number from 1 to 99.;id:ctl00_errMsg|div |
)

This test expects an error message to come up, since 5.3 is an invalid value.

!define NumberOfLevels {5.3}
!define Exists {Exists}
${ AssertValidInputNumberOfLevels}

The next test expects that no error message will appear, as 42 is a valid value.

!define NumberOfLevels {42}
!define Exists {DoesNotExist}
${ AssertValidInputNumberOfLevel}

(there are several more of these with different values, some which expect an error message, some which expect no error message)

In the browser these look like this, so they’re perfectly easy for POs or anyone to read.

Is this something everyone does and I just didn’t run across it before?