Talking testing, agility and automation... and anything else.



26
Apr 14

Running Test Suites In Geb

sweetsMaybe you’re looking to run a number of tests against a new build, or perhaps you just can’t wait for the overnight Jenkins tests to run. Whatever the reason, running multiple Geb tests/specs from your IDE is a snap, thanks to JUnit’s sweet suite functionality.

To the code!

We use two annotations: @RunWith, to specify the runner to run the suite, and @Suite.SuiteClasses, that specifies an array of tests/specs we’d like to run. Just add any specs you’d like run in the array, with .class appended and separated with a comma.

Lastly, we have our actual class, which is left empty. All you need do is run the suite and all your specified tests will run.

I’ve added this code to my Geb examples project on GitHub, so you can play along at home!


10
Mar 14

Screencast: Creating Your First Test In Geb

In this screencast, I walk you through writing your first test using Geb and Spock. We’ll create a page object and a spec (test), and then run our new test on multiple browsers.

If you’re just getting started, you might want to take a peek at my Geb Quick Start and Project Overview screencasts.


23
Feb 14

Customize Page Navigation By Overriding Geb’s getPageUrl()

gebGeb’s page object pattern offers the ability to set a url for a page, that allows you to navigate directly to a page. The url is used when calling the to() method (eg. to myPage).

An application I’m working on includes dynamic elements in its urls; the urls contain a session token, and can include a return page, and/or various content IDs. This makes it essentially impossible to navigate directly to the page. And unless you’re testing app navigation, it’s better to navigate directly. It keeps your code clean and helps mitigate brittleness.

The solution I’ve come up with is to parse the current url and use it to navigate directly to my pages. To do this, I needed to override Geb’s getPageUrl() (thanks to the Geb user group on this!).

BasePage.groovy

In my example above, we override Geb’s getPageUrl with our own getPageUrl, added to a BasePage, that we’ll extend in our page object. In this new getPageUrl, we want to replace the page name in the url (eg. http://localhost/html#/PAGENAME/…). To do this we grab the current url and just replace the current page name with the target page. All the other elements in the url should be correct.

Now we also need to make sure normal pages continue to operate, so we first test to see if pageName property exists in the page. If not, we execute Geb’s normal url code. To get the target pageName, we add it as a static property to the page (instead of url), named pageName. The code would looke something like this:

MyPage.groovy

Now we can simply call to MyPage as you would with a page with a normal url. Not too shabby!


01
Feb 14

A Better Way To Handle Checkboxes in Geb

checkboxGeb is a great automation tool with a lean API but in some cases, perhaps a bit too lean. Case-in-point, checkboxes. Here’s how you handle checkboxes in Geb:

Not the end of the world but IMO, not good enough. It doesn’t read overly well and requiring you to know the value of the checkbox to verify it’s checked, is less than ideal. We can do better… by using modules.

Using a module, we can add methods for handling checkboxes, that are, IMO, easier to read and use.

CheckboxModule

Pretty simple; create a module and add four methods to it. Two that let us check or uncheck a checkbox, and two that verify it’s checked or unchecked. Because isChecked() would require knowing the value of the checkbox (lame), we simply check that is not, not checked (yeah, it hurts my head too).

Now we add the module to our page object and then use the methods in a test…

CLSearchResultsPage

CLSearchSpec

As usual, this code is available on GitHub


12
Jan 14

Spock: Test Framework With Creamy BDD Center

spock[1]Two things I’m willing to admit:

  1. I think it’s a bad idea to dismiss tools prematurely
  2. I think most BDD tools are crap

Delicious hyperbolic contradiction aside, it would probably be more accurate (and PC) to say I’ve yet to work in a situation where using tools like Cucumber or JBehave would make sense. I.e. these tools just don’t compliment my, or my team’s, workflow.

Enter Spock. Spock is a testing framework for Java/Groovy, that is very similar to JUnit, but also adds BDD-friendly specification, baked right in. With Spock, there’s no need to maintain a separate feature or spec file; no weird broken-English language to learn. Your code is the spec and the end result is clean, readable and maintainable.

Case in point: the following is a Geb test, written in Groovy and using Spock. This is working code from my geb-example project on GitHub.

This test, from my CLSearchTest class, which tests searching on Craigslist (had to use something :) ). With that in mind, the code above is probably very readable to just about anyone. I’ll break down what’s going on a bit…

We start by defining our test: 'searches with few results offer nearby results', which is also our method name. Method names are string literals (can have spaces).

Next we have Spock’s built-in code blocks, labeled given:, when: and then:. These three blocks represent the different phases of a test. Each block can also include an optional description to help with readability. A bit about each block:

  1. given: (optional): Think of this block as a setup. It gives you the optional ability to specify state.
  2. when: (required): This is where the meat of your test code will go. You can have multiple Whens and Thens but they must be used in pairs.
  3. then: (required): This block is for asserts. All code in this section must return true or your test will fail. This gives your reader an easy way to see what the test is actually testing!

This just scratches the surface of Spock’s offerings. You of course get a full boat of annotations (including my favorite, @IgnoreRest) and fixture methods, additional blocks, etc… Plus it runs anywhere JUnit runs.

Don’t get me wrong, the principals of BDD are sound but I want tools that work the way I do, not the other way around. When using Spock along with Geb’s page object pattern and selectors, and Groovy’s fabulous syntax, the resulting code is both elegant and readable. YMMV…