Paul Hammant's Blog: Fluent Selenium with an Angular application

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: github.com/paul-hammant/fluent-selenium-examples/commit/4354667316c9f6

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(..) quit 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 it’s codebase, and I’m going to go through them too, and see if there’s a benefit 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 Miško 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/elegant tests for Web 2.0 apps too.