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

Feb 15

Can You Give Me A Login?

P1000811-1QA folk are protective of their logins, and rightly so. We create users to test with, and expect their accounts to be in the state we left them in. It’s not convenience… it’s essential.

But Devs will ask you for a login to this server, or that server. So send them the link to the wiki page that describes how they can create their own logins, and even walk them through it if need be.

But if they still come asking for a login, try creating, and sending them a login with the username “lazydevs”. Problem solved :)

Sometimes the passive-aggressive solution is the right solution.

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…

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.

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.

Jan 13

Selenium-WebDriver vs Sahi

selenium.logoJari Bakken has a couple of nice example tests that show some of the differences between a Selenium-WebDriver test and a Watir-Webdriver test. I thought I would create another example to show how the same code could be written in Sahi.

Both of the following scripts perform the same test. The test itself is simple:

  1. Go to the Google Translate page
  2. Click the Detect Language button
  3. Select Norwegian as your language
  4. Log the button’s text
  5. Enter the word “ost” into the text field
  6. Verify “cheese” is the returned translateion

Selenium-Webdriver Example…

Sahi Example…

The difference is pretty dramatic… at least in test size. Sahi handles all your waits for you so there’s no need to clutter up your tests with wait code. Accessor code is also less verbose in Sahi. Overall, I would argue the Sahi code is much more readable but code beautry, like beauty in general, is in the eye of the beholder. I.E. your millage may vary…

Note: I used an assert instead of just logging the returned translateion… same dif

UPDATE: I’ve also added Geb to the fray!

Dec 12

Should You Just Stop Tracking Bugs?

With apologies to Ian Betteridge for the hyperbolic headline, I wanted to share this 6 minute lightning talk in which Jon Tørresdal argues for “The simplest solution to bug tracking: don’t!”.

To paraphrase Jon’s list of 5 “crazy ideas”:

  1. Don’t track bugs; just fix them
  2. Delete all bugs in your backlog that you can’t fix immediately
  3. All newly reported bugs are either rejected or fixed immediately
  4. Automated tests are created for each new bug
  5. Set WIP limit for bugs (eg. 20 total)

Ten years ago I would have scoffed at the idea of not tracking bugs and deleting the bug backlog, but today, I can see this as a realistic possibility. In fact, this isn’t far from how my current team operates today. So what’s stopping me from going all in? Guts?