BDD Ideas

In some meetings here, we've come up with some ideology of the Given, When, Then's.

Given's are seen here as having all the data set up. 

So a test shouldn't say:

Given a user logs in
and clicks continue
and clicks home
and clicks... etc.

If all of that is data set up, it would all be in the Given, like:

Given a user logs into the site and continues to the Personality page.

All the actions to get to that point, should be covered in the Given.

As for the Then, the Then area in GEB is always taken as true or false.  For this reason we don't need to define assertions.  assertions are given.  so instead of:

assert $("h3.title").text().equals("Questions")

we can just say
$("h3.title").text().equals("Questions")

Utilizing Static 'content'

In GEB I started utilizing static "content" with my assertions.

Here's how it works.  My tests have been getting messy.  Lots of assertions stacked into the tests.  So to clean it up a bit, I was advised by a developer here, to put the assertions into the page object's static content.

In the page object, we have this:

static content = { 

}

In between the brackets we can define the assertions for this page, like this:

static content = {

        basicsOccupation {$("td.header", 0)}
        basicsAge {$("td.header", 1)}

}

Now, in the test, I can reference these assertions like this:

   then: "All page elements load without problem"
            basicsOccupation.text().equals("Occupation:")
            basicsAge.text().equals("Age:")

This makes the test itself look clean and more human readable.

Making Tests Modular

In a recent code review, the VP of technology gave me some good advice.  He looked at a test I had, and in the test, I was validating all the elements on the page in question.

He suggested I stop doing that, and instead focus a test's assertions just on a module basis.  So if a page has 4 modules (Basic Info, Photo, Next Steps, SiteNav), to not make assertions for all items - but instead have a test that only checks assertions on Basic Info, then another test with assertions just for Photos, then another test with assertions for Next Steps and so forth.  So each test, just focuses on a specific module. 

The idea here is to remove the complexity and thus brittleness of the tests themselves.

Validating Strings with .equals

I was making some assertions lately, and one of the dev's here gave me some advice.

My assertions in GEB were like this:

$("td.header", 0).text() == ("Occupation:")

But I was advised that using == is when checking an Object.  When checking a string, I should use .equals.

So instead I used:
$("td.header", 0).text().equals("Occupation:")

GEB: Handling different elements with same identifier

Yesterday I had a situation where I was writing an automation script in GEB to check data in a page.  The page was created, with a table with multiple rows. Each row had a class element.  It seemed easy, until I realized, that each row was given the same class element name. 

So the table looked like this:

<td class="header">Occupation: "</td>
<td class="header">Age: "</td>

So when I tried to do this:

assert $("td.header").text() == "Occupation:"

assert $("td.header").text() == "Age:"

it would fail.  It was failing because it kept hitting the first element named "header" and wouldn't go to the second one.

I found the solution to this problem from the Book of GEB.  The way to work around this, is to use a built in GEB format.  GEB can run through elements, much like an array, by simply appending the numeric of the element in order.  0, being the first.  so in my example, Occupation would be 0, Age would be 1.

The code then looked like:

            assert $("td.header", 0).text() == "Occupation:"
            assert $("td.header", 1).text() == "Age:"

It worked perfectly.