Automated Web Acceptance Test Framework – now in Ruby!
Over a year ago, my colleague Tristan posted on the OpenCredo blog about a test automation quick start framework. It’s a prepackaged framework you can clone and get going with testing instantly, rather than wasting your time rebuilding your framework every single project. We have used this framework successfully used on many of our internal projects, and it relies upon a Java, Cucumber-JVM and Selenium stack.
This is great if you like Java – but if you don’t, then you’re not in much luck! You may be aware that Cucumber was originally written in Ruby – and that there are lots of great testing libraries available for Ruby. You may also just be more familiar with Ruby, or prefer dynamically typed languages.
So – I’ve put together a web acceptance testing framework in Ruby, taking advantage of some of the best practices out there, and a lot of the awesome stuff people have already done. From nothing, you should be able to start running tests in minutes, and you’ll have a lot of powerful tools at your disposal, including parallel test execution, Browserstack integration, and headless browser testing.
The project is available here on GitHub, along with instructions of how to set it up and what kind of things you can do with it.
Tests and documentation written in plain English
Cucumber allows users to write plain English tests. This allows non-technical users to understand your tests, allowing greater collaboration between the business and developers. It even be very useful just having a human readable layer to your testing. Also included is Relish, which automatically creates and uploads your readable features for the entire team to see – here’s the example for this project.
Page Object patterns
Page Objects are a standard pattern with automated tests, representing the interactions within the page, and hiding the implementation details, making your test suite much more maintainable. This framework uses the SitePrism gem which provides a powerful DSL to create page objects with.
Parallel test execution
I have written before about how test execution speed can become a bottleneck. Cucumber normally waits for one test to finish before starting another – but there’s no need for it to. This framework will fire up many instances of your browser and execute tests across all of them, bringing your test set execution time down, and will help you find bugs much faster and deploy your application more frequently.
Ability to execute in different browsers locally
Support for remote execution across hundreds of different browser versions
If you’re developing a webapp with a large userbase, you’ll want to test it against as many browsers as possible. The traditional way to do cross-browser testing is to hand roll and maintain machines yourself. You may even have a suite of configuration controlled machines/containers available. Unless you have very specific requirements, it’s probably easier to run on Browserstack, which gives access to a very impressive library of preconfigured browsers. All you have to do with this framework is configure your login and required browsers.
Headless browser testing
Headless browsers are browsers without a graphical element – they exist in the background. Whereas we would encourage a full UI test against your application before deployment, headless browser tests are far quicker and consume less resources, meaning they can be an effective first round of tests to find bugs.
Ruby is a very flexible language, meaning you can write domain specific languages (DSLs) very easily. DSLs make code for specific tasks far more readable, and thus easier to work with. This framework uses Capybara for Selenium, SitePrism for Page Objects, and RSpec expectations for readable assertions.
Test data persistence
Cucumber typically doesn’t encourage data to be communicated across test steps or saved for later. This framework provides the ability to store data in a centralised store, and retrieve it later via an alias.
Randomised data generation to prevent data collisions
Test data being hard coded into tests is a pervasive anti-pattern. You have to co-ordinate which tests use which data, as well as working out their dependencies. We encourage the setup of random test data as part of the test itself, explicitly declaring its dependencies. This means you can run any tests multiple times, without worrying about managing your data manually or resetting your application database. Even better, because the data is aliased, it can still be referred to between test steps, with a non-random name.
If you wish to use the framework, then installation and usage instructions are available over on GitHub (and of course, if you want to contribute and submit a pull request, you can!). The framework comes with a number of test cases you can run, as well as show you how to implement extensible, scalable test suites. The real benefit of test automation comes with large, stable test sets, which is why it’s so important that you start with a solid foundation!