SitePrism 2.1 is out, and thanks to a pull request from 3coins you can now use xpath instead of css if you like. Take a look at the docs here: http://rdoc.info/gems/site_prism/file/README.md#CSS_Selectors_vs__XPath_Expressions.
As usual, find SitePrism here: https://github.com/natritmeyer/site_prism
I’ve recently come across a problem when doing UI testing with Firefox on a Mac against a web app that uses NTLM authentication. Every time I navigated to the web app I was presented with a dialog box asking me for my username and password.
I did some reading and came across Alister Scott’s Automatic Firefox authentication when using Selenium-WebDriver with AutoAuth post. In it he explains a way to get around the problem:
- Create a Firefox profile using the profile manager
- Add the required credentials to the profile
- Use the above Firefox profile when running tests
- Add the AutoAuth plugin to the profile at test execution time
The above would get around my problem, but it would lead to having to maintain a firefox profile which isn’t nice. So, I decided to attempt writing a firefox plugin that would allow me to add credentials to firefox’s password manager at runtime using Javascript. After all, according to the documentation it looked possible…
After a bit of hacking, the result is my first Firefox plugin: the Test Automation Password Manager plugin. It’s quite simple to use; you can find instructions here:
https://github.com/natritmeyer/test_automation_firefox_password_manager
…and the plugin page here:
https://addons.mozilla.org/en-US/firefox/addon/test-automation-password-ma/
I’ve not tested it extensively – “It Works On My Machine” 
It’s time for another update to SitePrism. Version 1.3 provides the ability to wait for the visibility or invisibility of an element or section.
SitePrism 1.2 was released earlier today, an upgrade that lets you interact with iframes. Take a look at the iframe section of the README for an example.
So, it’s time to…
bundle update
…or…
gem update site_prism
I needed to get a list of all the tags used in a cucumber project, and what follows is the formatter I wrote to list them all for me.
To use it, save the code in a file called list_tags.rb and then execute the following command:
cucumber -d -f Cucumber::Formatter::ListTags
Done!
In a fit of insomnia over the weekend, and prompted by a feature that arrived in a pull request from Remi Taylor, I released SitePrism v1.1.1. It’s a minor release, and from it you can expect the following:
The page object model works very well, but there are a few traps you can fall into. Alister Scott goes through a few of them and mentions one that particularly grates me: “Pages stored as instance variables”. Here’s a demonstration of the problem:
So why is that a problem? Well, there’s lots of noise – 3 lines are there just to create variables. This significantly reduces readability as you’ll end up with many, many lines of test code just creating instances of page objects. You also now have a whole load of instance variables to keep track of: @login_page, @account_page, @account_history_page. And when you’re using cucumber to run your tests, this will lead to *big* maintenance issues. I’ve had to rescue a few cucumber-based test projects and one of the most frequent causes for test-rot is that the testers lost track of their instance variables. Been in this situation before?
“Can I use @account_page here? Did I previously declare it? Hmmm… No, it’s nil when I try to use it. OK, I’ll instantiate it here. [runs the tests]. Cool, that works. Oh no! Doing that has broken some other tests that referenced @account_page but expected something else!?!? Should I fix up the other tests? Rename the @account_page variable to something else? If I do that will I break anything else?” Not fun. Big spaghetti problems.
But what to do about it? Alister suggests using blocks (provided by the page-object gem) that look something like the following:
On first glance, this looks great. No instance variables to keep track of. Just deal with the classes themselves and use only local variables inside the blocks. Nothing to keep track of. Great!
But…
The above proposal causes other maintenance hassles – the page object’s class name is now scattered throughout the code. Lots of “visit LoginPage” all over the place. What happens when the class name changes? You’ll have to make changes throughout the code. Not fun.
Solution: use an instance of an App class, this App class being a representation of the app you’re testing (the whole app, not individual pages). This App class contains one method per page class, each of these methods return an instance of the relevant page class.
“Whhhaaattt?”
OK, here’s an example:
In your tests, you would then have the following line:
When I visit the login page
…which would match the following step…
If you structure your tests such that they always begin by mentioning where the user starts (a good idea as it gives context), you can rely on the fact that @app has been instantiated so you can just use it. For example:
So how is this an improvement? Well, there’s no need to manage instance variables for different pages – just call methods on a known instantiation of the App class(@app) and they’ll return instances of the pages you want. There’s no need to mention class names; they are hidden behind methods. If the class name changes you only need to make one change (change the class referenced in the methods in the App class).
Subjective statement: I’d also argue that you also get great readability with this way of structuring things.
This is how I’ve normally organised things. And it’s worked great both on small projects of only 10′s of tests to large projects where the number of tests is 1000+. It’s the best solution I’ve come up with, it doesn’t suffer from having instance variables all over the place, neither are there class names all over the place.
I’ve written up in brief how this works if you’re using SitePrism to manage your page objects: http://rdoc.info/gems/site_prism/file/README.md#Epilogue
While RSpec is great, it is missing a built in JUnit formatter so you don’t get the pretty analysis stuff from Jenkins that you otherwise would. There have been a few attempts at writing an RSpec JUnit formatter, but I’ve never seen something work consistently across versions of RSpec. In my experience, the ci_reporter gem works well, but only with some versions of RSpec. Since it doesn’t work with the current version (2.10), I decided to write my own simple JUnit formatter that will allow me to run my tests in Jenkins. To use it, save the code that follows to a file called junit.rb and then call rspec with the following options:
rspec my_spec.rb -r ./junit.rb -f JUnit -o results.xml
That will cause RSpec to require the file containing the formatter, invoke the formatter and save the JUnit-formatted results to a file called results.xml. A better option would be to require the junit.rb file from your spec_helper.rb file (which in turn is being required by your .rspec file, right?). If you do that then you’ll only need to call the following:
rspec my_spec.rb -f JUnit -o results.xml
Anyway, here’s the code. Hope it helps!