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

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:

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):

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:

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

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.

Plusone Linkedin Facebook Twitter Digg Email

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:

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

Plusone Linkedin Facebook Twitter Digg Email

Feb 16

Protractor: How To Page Object

bookPage objects, for lack of a better word, are good. Page objects are right. Page objects work.

And if you’re writing e2e tests, you should know what they are, and how to use them. Let’s page object!

What is it?

You’ll find a veritable plethora of definitions and examples on the webs… or TLDR: page objects create a user-centric model of your application.

Why should I care?

This page object model is then used to manipulate your application, abstracting away the html/css from your tests. The benefits are many:

  1. saves maintenance time: updating the page object updates all tests that use it
  2. organizes your code and keeps it DRY
  3. declutters your spec files by moving logic to the page object
  4. use a cool buzzword that is actually useful!

How to page object?

A simple page object:

Let’s go line by line…

We use a constructor to create our page object. We could (and I sometimes do) use an object literal, but not when I’m extending a basePage (a topic for another post).

Here we start creating our model by setting this.username to our app’s css (using Protractor’s JQuery-like $ locator).

The idea here is that in our tests, we’ll call this property, githubPage.username, to refer to the app’s css code. This save us from having raw selectors (eg. $('div.vcard-username') ) strewn about in our tests. Thus, if (when) the css changes in your application, you simply update the page object, and you’re green again. No hunting for uses through tests. It also makes your tests read better, and just look cleaner. You should never have raw selectors in you tests… keep ’em in the page object.

We’ll also put methods in our page object:

We’ll also add methods to our page objects. Here we create a method for hitting the enter key; something we’ll use throughout our tests. This not only keeps wonky looking webdriver code out of our tests, it also keeps our code DRY.

Examples of when you might want to add a method to your page object:

  • actions you’ll using in multiple tests
  • actions that take multiple steps: eg. enter search text and hit return
  • wrap selectors or wonky looking webdriver code
  • wrap another method and add logging or whatnot to it

And finally, we use Node’s module.exports to create a reference to our page, that will allow us to require it in our tests. Note, we also instantiate it here, by using the new keyword and parenthesis. I’m not a fan of instantiating a page object within a test… it’s cruft that should be done elsewhere whenever possible.

That’s the basic gist. For more examples, take a peek at my working Protractor example project up on GitHub

Plusone Linkedin Facebook Twitter Digg Email

Aug 15

Protractor: Navigating Pages Without Angular

compassI’m currently using Protractor to build e2e test automation for my team. And while Protractor is especially helpful for Angular applications, my app is non-angular. This has presented some challenges… and because of it’s asynchronous nature, some truly maddening challenges at that :)

Case in point: page loads.

Because I don’t have Angular telling Protractor when a page has finished loading, I need to handle it myself. Thus I stole some ideas from my work with Geb, namely, the to() and at() methods. These two methods navigate to, wait for, and verify all page changes. Here’s how it works…

First, in my basePage (that is extended from all other pages), we have two friendly methods:

These methods rely on each page having the properties url and pageLoaded. For example, the page object could include:

The url property is just a string. It can be fully qualified, or relative (which then gets appended to the baseUrl). The pageLoaded property uses Protractor’s Expected Conditions and() method, that allows you to use any number of functions to both wait for the page, and test that we’re on the correct page.

In this example, I only need one EC function, hasText, but you can add as many as necessary, separated by commas (eg. you could wait for a spinner to NOT be displayed, for a header to be displayed, AND check the page title). Each function need only return true.

Finally, we can call these in our specs thusly:

In the beforeEach block, we call, which calls both the to() method to navigate to the page, and the at() method to wait/verify the page.

Then in the spec, we click on the home page link, and use at() inside an expect() to verify we’re on the right page. We can do this because we return the result of the Expected Conditions. If all are true, the test passes; if even one returns false, the test fails.

The result is a clean way to navigate pages without Angular.

I use this in my protractor_example code up on the GitHub

Plusone Linkedin Facebook Twitter Digg Email

Jun 15

Charter Communications Sucks

dinosaurMy current ISP is Charter, and yes, like all of their brethren, they suck.

For the past four years I’ve signed up for their two year, $40/mo, internet-only program, which they DO NOT ADVERTISE, but will begrudgingly give you if you call and cmplain enough. Well two months ago this ran out. I called to sign up for another two years… only to find out they now REALLY, REALLY don’t offer it anymore. So after three calls, I eventually believed them… for reals. Hardball. Fine.

They raised my rate to $67 a month…. ouch.

So I paid the first month and looked around at ANY other provider. But, as they know, there are no alternatives that don’t also suck ass. Lame.

So I got my second bill from them today and decided… fuck them. I called and told them I wanted to cancel, and that it was because of the price. They then offered me another year @ $40/mo.

Clearly I wasn’t complaining enough!

This is less than ideal customer service… and yet it seems to have become an industry norm. And while 1/3rd of Charter’s business (internet), is killing the other 2/3rds (phone/tv), at least this gives them a step up on car salesmen and realtors for “most annoyingly tolerated, unnecessary, service providers on the planet” award. For now.

Anyway, I won’t say “problem solved”, but I’m willing to celebrate “problem temporarily averted”. I look forward to the day when some Google-sized meteor finally kills off these dinosaurs.

Plusone Linkedin Facebook Twitter Digg Email