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
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.