launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

Hi

I just wanted to share a problem that I got snagged on in case anyone
else comes across the same thing. The issue affects Windmill tests and
causes them to error with a client timeout exception. For me, it only
started happening recently when I wrote a new test but around the same
time also showed up on ec2 for other existing tests that I didn't write.

When writing a Windmill test, you can wait for a page element like a
button to appear so you know the page is loaded, before moving on to the
next step in the test. This can be done like so:

ADD_COMMENT_BUTTON = (
    u'//input[@id="field.actions.save" and contains(@class, "button")]'
client.waits.forElement(xpath=ADD_COMMENT_BUTTON)

See that the xpath expression checks for the expected class of the
element? Well, when I first wrote the test, the xpath I used was this:

ADD_COMMENT_BUTTON = (
    u'//input[@id="field.actions.save" and @class="button"]'

Note the difference. When I inspected the page source on edge to figure
out the xpath expression to use, the class of the button showed as just
"button". So why was the waitForElement failing then? Well, it turns out
that there's some async processing which goes and updates the class to
class="button js-action" (thanks thumper for enlightening me on that).
So, clearly the more robust and correct way to do the xpath is to use
contains, as in contains(@class, "button").

I fixed my test and went through the existing Windmill tests and found 2
other cases from bugs.windmill which used class="button". From memory,
the tests concerned were also the ones intermittently failing recently
on ec2 (but I've drunk way too much red wine since then so my memory may
be a bit hazy). Anyway, it all makes sense now.

So, bottom line, when you write your Windmill tests, please remember to
use contains() where appropriate when constructing your xpath
expressions, to ensure the tests are robust and immune to these subtle
race conditions/timing issues.