Talking testing, automation... and anything else.



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…


07
Jan 14

Geb vs. Sahi vs. Selenium-Webdriver

gebAs an addendum to my original post comparing Selenium and Sahi, I offer the same test written in Geb.

Sidebar:
I took a bit of flack for the original article, mainly people complaining that my comparison wasn’t an apples to apples comparison. Their argument was that because they share a more similar architecture, a more fair comparison would be to compare Sahi to Selenium RC. Of course this argument is complete rubbish. My comparison was (and is) merely a look into the raw code of each tool. But even if it wasn’t, Sahi and Selenium both aim to provide the same function: web application automation. Comparing these two tools is completely valid… though I do profess to enjoy the modicum of hyperbole. That all being said, I will paraphrase Mike Watt and say: “if you don’t like it, go out and start your own blog!”

Anyway, I’ll throw Geb’s hat in the same ring with one disclaimer: Geb runs on top of Webdriver… WORLD BEWARE. Please feel free to breath into a paper bag or the something…

Now, without further ado, I give you [gasp] the Google Translate test, written in raw Geb (no developers were hurt during the coding of this test (unless you equate drinking most of a bottle of wine to being “hurt” (which I do not (because I live in Wisconsin)))). Enjoy responsibly!

Download the working code from GitHub…

Note: this code, like the original Sahi and Selenium code, is “in the raw”, as it were. I.e. no page objects or custom methods to help readability/maintainability/*.ility.


04
Jan 14

Organizing User Data In Your Geb Tests

gebGeb offers a number of conveniences for writing Selenium Webdriver tests but it draws the line at organizing data. Lacking a sanctioned solution, I rolled my own, making use of Groovy maps (hashes).

Here’s an example of how I’ve been organizing my user data. The following code is a working example (thanks Moodle!) and you can download the full example code from GitHub.

Pretty simple. I created a package named data, added a UserData class file to it, and filled it with four maps, one for each user our example app.

Then we use it thusly…

We assign one of the user maps to a static property, admin(line 6), then use that property to log in (line 13), and then to verify we’re logged in (line 20).

This approach can really help improve code readability and offers one location to organize all of your data. It can also help with test maintenance, as changes to data need not require updating your tests. This works well for user data but should work with just about any kind of data.


22
Nov 13

Geb: Get Selected Text From A Select Dropdown

gebMy current client has decided to migrate their automated ui tests over to Geb, thus, I’ve been busily ramping up on it for the last couple weeks. Geb, written in Groovy, sits atop Selenium Webdriver and provides some great conveniences, including elegant css selectors and page object support. Additionally, using Spock as your test runner allows you to write your tests in a given/when/then dsl.

I’m finding Geb to be a great tool but like all tools, it has its quirks. Take getting the currently selected text from a select box… Geb does not currently (0.9.2) have an api for this. It has support for getting the currently selected value but you’ll have to do a little work to get the selected text. With a little trial and error (heavy on error), I was able to craft a reasonable solution to this problem in a page object selector. Here’s my example code…

Page Object Code (TestyPage.groovy):

Test Code (testy.groovy):

The trick here is in the page object. In the selector dropdownSelectedText, we use .find to get the first option tag, down the dom from dropdown, that has a value of dropdown.value() (in this case ‘ggg’) and then get the text from that option tag.

Reasonably clever…