HTML5 Zone is brought to you in partnership with:

Paul is a principal consultant at ThoughtWorks. He is enthusiastic about open source in particular. He is known for Dependency Injection (one of its pioneers with PicoContainer), Selenium browser automation (co-founder), Branch by Abstraction and most recently Client-Side MVC frameworks. Paul is a DZone MVB and is not an employee of DZone and has posted 69 posts at DZone. You can read more from them at their website. View Full User Profile

Fluent Selenium with an Angular Application

09.30.2013
| 2324 views |
  • submit to reddit

It took 90 minutes to make a Fluent-Selenium test of Jimmy John’s online booking app that is written in AngularJS. Here is the commit for that.

And here is the video of it running (22 seconds):

AngularJS and Fluent Selenium

There’s no use of within(..) for the tests at all. The Etsy.com and Hipmunk.com tests in that suite use within(..) quite a lot, and there was some trial and error to get that right. With this one for Jimmy John’s AngularJS app, we’re using a hook into Angular that basically blocks until the AngularJS is no longer doing things. This feels much more first-class.

I’ve cribbed code from Protractor (Angular’s new testing framework), which uses WebDriver (Selenium 2.0) to push through some glass-ceilings versus Karma (their previous test framework). You can see that in the diff: the static ngWait() method.

There are more WebDriver-enabled locators that Protractor has in its codebase, and I’m going to go through them, too, and see if there’s a benefit to having them duplicated for Fluent-Selenium usage, versus the locators we have now.

Karma is the renamed Testacular framework. Before that, the Angular co-creator, Misko, pioneered JSTestDriver in about 2009. I remember the first first version of Selenium that Jason Huggins showed me in 2004. It used a similar iframe approach to testing applications (but with a rudimentary HTML test grammar). My contribution was the start of Selenium-RC and Comet-style steerage from other languages, but that’s a little off topic. Selenium 1.0 was scarred by the inability to actually listen on a socket for instructions from the driving code/process. Many years passed with only small improvements to counter the limits born from that. When WebDriver (and Simon Stewart) performed a welcome reverse takeover of the Selenium project, that glass ceilings was conclusively punched through. Sure, the codebase became an order more complex, but it was worth it. I think with the rise of Protractor, Angular’s testing capability has lifted too, and for many of the same reasons.

Other Technologies

If other JavaScript technologies (Backbone, Knockout, etc.) had hooks to allow for effective waits, then they’d be as easy to test too. Old-style Web 1.0 apps are incredibly easy to test using Selenium/WebDriver already, and it’s nice to be able to use better tooling to make terse and elegant tests for Web 2.0 apps too.

Published at DZone with permission of Paul Hammant, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)