Last week I was exploring today’s varied choices we have for Automated Browser Testing. There’s headless WebKit “browsers” like PhantomJS and cloud powered multi-browser testing tools like BrowserStack and SauceLabs.
Selenium is kind of the gold standard and offers not only a lot of “drivers” but also a lot of language bindings with which drive a browser. Sometimes browsers update so fast there can be some version incompatibilities with Selenium, but for the most part it works great once you’ve settled in.
One option I’ve been looking at is FluentAutomation. It’s a fluent automation API that supports Selenium as well as WatiN along with all their flavors and drivers. Since Fluient supports Selenium, that means you can use the Selenium ChromeDriver, IEDriver, Remote Web Driver or even the headless PhantomJS.FluentAutomation is on GitHub, of course, as well as on NuGet.
FluentAutomation has great (and growing) documentation and has adopted and interesting fluent style for it’s API.
Now, not everyone likes a “fluent” API so it may take a while to get used to. Often you’ll be doing things over many lines when it’s really just one line, for example, this is one line:
Notice the method chaining as well as the use of CSS selectors.
FluentAutomation also has the cool concept of a PageObject to take your potentially brittle scripts and give them more structure. PageObjects group your actions, expectations, and assertions and let you reuse code when a page appears in multiple tests.
For example you could have a high level test (this is XUnit, but you can use whatever you want):
Then you can have separate PageObjects that have your own public methods specific to that page, as well as assertions you can reuse.
You don’t have to be all structure and OO if you don’t want. You can just as easily write scripts with FluentAutomation and head in a different direction.
FLUENTAUTOMATION ALONG WITH SCRIPTCS = AUTOMATING YOUR BROWSER WITH C# SCRIPT
I’ve usually used Python with my Selenium scripts. I like being able to just make a text file and start scripting, then run, debug, continue, all from the command line. It feels simple and lightweight. Creating a DLL and running Unit Tests in C# usually comes later, as I can move faster with a “scripting language.”
You can do that with ScriptsCS as it gives you project-less C# that effectively is C# as scripting language. Combine this with FluentAutomation and you’ve potentially got the best of both worlds.
To install, first you need the Windows apt-get open source equivalent, the oddly-named and -spelledChocolatey. Then you get ScriptCS and the packages for FluentAutomation.
- Install Chocolatey – one line installation here
- Run “cinst ScriptCS” from your command line to use Chocolatey to install ScriptCS
- Now, get the ScriptCS script packages for FluentAutomation like this:
- scriptcs -install FluentAutomation.SeleniumWebDriver
- scriptcs -install ScriptCs.FluentAutomation
Now, as a quick test, create a folder and put a text file called start.csx in it with just these contents:
Notice how there’s no namespace, no classes, no main. It’s just a script, except it’s using C#. You can change the “Chrome” to “IE” or “Firefox” as well, to play around.
Random: I love this Selenium feature, exposed by FluentAutomation…take screenshot!
If you don’t want ScriptCS, while it can act as a REPL itself, there is also the start of a dedicated FluentAutomation REPL (read–eval–print loop). This is basically a command prompt that lets you explore you app interactively and facilitates building your scripts. You can get the Repl as a Chocolatey package as well and just “cinst FluentAutomation.Repl”
You’ve got LOTS of choices in the world of automated testing. There’s so many choices that there’s just no good excuse. Pick a library, pick a language, and start automating your web app today.
- Explorative Web application scripting using scriptcs and FluentAutomation video and blog post.
- FluentAutomation homepage