Amtrak, B-Movies, Web Development, and other nonsense

Tag: Behat

Pick a date, any date

Moodle 3.2 introduced the concept of end dates for courses. Moodle 3.3 added a new Course Overview block which uses end dates to determinate whether a course is in progress, in the past, or in the future. This is pretty great, unless you’re in the following situation:

  • Your school has five years worth of courses
  • Those courses don’t have end dates

Congratulations—you now have five years of courses in progress. Your faculty will have five pages worth of past courses on the Course Overview block! That’s probably undesirable. To avoid it, I’m writing a plugin that lets an administrator set course start and end dates at the category level. While working on it, I ran an interesting edge case with Behat acceptance tests, reminding me that you’d best treat Behat like it’s a real user.

Continue reading

Wait, let me finish!

This summer we have our student worker building out a set of Behat tests for our WordPress environment. We’ve started with smoke tests. For example, on www.lafayette.edu we’re looking at the following:

  • Are there news items? If so, do the links to those items work?
  • Are there calendar events? If so, do the links to the events works?
  • Does the “Offices & Resources” drop-down function? Do the links in that drop-down work?

That’s a short list of tests but it covers a lot of ground:

  • The RSS feed validity between the main site and the news site
  • The RSS feed validity between the main site and the calendar
  • Whether Javascript still works on the main site
  • The proper functioning of every link in the drop-down

If any of these tests fails there’s a non-trivial problem with the main page. In the first iteration, we ran into a problem with testing the links in the drop-down. This was the original test:

                When I click on "#navResources-toggle" 
                And I click the link <link>

This was within a Scenario Outline testing each link. It failed, each time, with some variation of the following:

 Exception thrown by (//html/.//a[./@href][(((./@id = 'foo' or contains(normalize-space(string(.)), 'foo')) or contains(./@title, 'foo') or contains(./@rel, 'foo')) or .//img[contains(./@alt, 'foo')])] | .//*[./@role = 'link'][((./@id = 'foo' or contains(./@value, 'foo')) or contains(./@title, 'foo') or contains(normalize-space(string(.)), 'foo'))])[1]
 unknown error: Element is not clickable at point (573, -163)

Googling suggested fiddling with the click location, which didn’t feel right. Triggering a drop-down menu and clicking a link is a simple enough use case. Simple problems should have simple answers.

Turns out this is a race condition and it reveals something about behavioral testing. The drop-down menu on the main page doesn’t open right away. We have some easing, timeouts, and animation which all mean that it takes a second or so to finish loading. During that time the links are actually moving from their starting point at the top of the page. Go try to clicking on the menu and you’ll see what I’m describing. This means that a normal user will wait for 1-2 seconds before clicking a link. We didn’t write the test that way, which meant that the location of link changed from the time we told Behat to click it and when Behat tried to click it.

The solution? Write the test like Behat is an actual user and build in that delay:

                When I click on "#navResources-toggle"
                And wait 2 seconds
                And I click the link <link>

The order of operations matters. Now, Behat doesn’t click the link until two seconds have passed, at which point the drop-down is done expanding and the links are in their final location.