Talking testing, automation... and anything else.

Selenium-Webdriver

Automation / Code / python / Selenium-Webdriver / Testing — No Comments
06
Nov 18

Selenium Testing in Python and Pytest

My experiences with Python have always been amicable (if not brief). It’s for just this reason that I’ve always wanted to try out Selenium Webdriver’s Python bindings. **SPOILER**: I did just that and you are now reading about it!

When learning a new language (or tool or job or…), I try and keep my opinions to myself. It’s funny how often something that seems weird/silly/stupid at first, will eventually have a reasonable explanation (except you, PYTHONPATH… I still think you’re pretty silly).

Pytest is a good example of this. Where other bindings generally offer a number of helper-frameworks that smooth out the rough bits, Python folks seem to embrace the vanilla bindings. This puzzled me a bit… until I discovered Pytest.

Pytest is a bit of a Swiss Army knife for Selenium testing in Python. It’s a test runner; uses fixtures to handle setup/teardown (and a ton more); handles test discovery; has detailed reporting; makes excuses for unwanted lipstick on your collar. It does most of the heavy lifting for tests.

Ultimately, I found Python’s concise syntax and explicit code conventions make it a great language for functional testing. I’ll cover more details in upcoming blog posts.

Take a peek at the code up on GitHub…

Automation / Blather / Code / How-Tos / Protractor / Selenium-Webdriver — No Comments
18
Dec 16

Re-Run Flakey Tests with Protractor-Flake

If you’ve worked with E2E tests for any amount of time, you will have experienced tests that, for whatever reason, randomly fail; aka flakey tests. Such failures can be caused by any number of things: a network glitch, browser barf, app hiccup, act of God, etc…

Test flake can seriously undermine the trust in automation, and drive your automation engineer to drink (or perhaps just drink more). A wise test engineer will embrace that flake happens, and account for it in their automation strategy.

One popular strategy is to re-run failed tests. This way, if a test fails, it gets re-run ‘n‘ number of times, and if it passes, life is good. Enter Protractor-Flake.

Protractor-Flake parses your Protractor test output, looking for failures, and re-runs any failing tests (note: at the spec file level) at the end of your test run. It works really well and is simple to setup. Here’s how…

First install it as a dependency:

npm install protractor-flake --save

Then you can run it directly by using it in place of Protractor (note: the ‘–‘ denotes the end of args passed to protractor-flake, and the beginning of args passed to Protractor):

node_modules/.bin/protractor-flake -- conf.js

Or you can use it programmatically. I like to create a simple node script, which allows me to add logging and reporting (future blog post). Here’s an example:

#!/usr/bin/env node

var protractorFlake = require('protractor-flake');
// skip first two args (node and self)
var protractorArgs = process.argv.splice(2);

protractorFlake({
    protractorPath: 'node_modules/.bin/protractor',
    maxAttempts: 2,
    parser: 'standard',
    nodeBin: 'node',
    protractorArgs: protractorArgs
}, function(status, output) {
    process.exit(status);
});

Saving the above script as a file, 'flake', you could then run your tests thusly:

./flake conf.js --baseUrl=http://qualityshepherd.com

Now obviously, you should be killing off flakey tests to the best of your ability, but Protractor-Flake can save you from non-test-related flakiness, and keep your tests green! You can see a working example in my protractor-example repo on GitHub.

Automation / Protractor / Selenium-Webdriver — 3 Comments
11
Dec 16

Chrome Hangs During Protractor Test Runs On Ubuntu

light-bulb-idea-icon-clipart-panda-free-clipart-images-h1fryo-clipartQuick Tip: I run Protractor tests, headlessly via XVFB, on a Ubuntu server (blog post on this to come), and was seeing Chrome annoyingly hang during test runs. I was constantly having to manually kill the chrome processes, and also an associated BrowserBlocking process. After a bunch of debugging, and searching, I finally found the solution. This simple env var fixes it:

export DBUS_SESSION_BUS_ADDRESS=/dev/null

Just add that to your .profile file, and you should be good to go.

Automation / Code / How-Tos / Protractor / Screencast / Selenium-Webdriver / Tools — No Comments
16
Nov 14

Screencast: Protractor Test Automation Framework Example Code

I’ve been playing around with Protractor, a great, new(ish) testing framework from our friends at Google. I’ve shared my example code on GitHub for those that might be interested in such things.

Examples in the code include:

  • Using page objects
  • Running on TravisCI
  • Running tests on Sauce Labs and Browserstack
  • Running multiple browsers at once

I’ve also made a quick screencast that walks you through downloading and running the example code.

Cut to the chase, in the video we:

  • Install Node (okay, I don’t show this but you need do to it!)
  • Download the example code from GitHub
  • run npm install to install the project dependancies
  • Briefly discuss a config file
  • run protractor conf.js to run the tests
Automation / Code / Geb / Hyperbole / Sahi / Selenium-Webdriver — 10 Comments
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!

import geb.Browser

Browser.drive {
    go('http://translate.google.com/')

    $('div#gt-sl-gms').click()
    $('div.goog-menuitem-content', text:'Norwegian').click()
    $('textarea#source') << 'ost'

    waitFor {
        $('span#result_box').text() == 'cheese'
    }

    quit()
}

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.

← Older Entries