Finally I got around using functional testing (some people call it ’System Testing‘) extensively in a project. This post lists what I’ve learned about functional testing and more specifically, Geb, which allows you to automate functional tests.
Let’s start with defining what I understand by ‘functional test’: a functional test is run against a fully running web application, which is on a dedicated environment (more on that later). Functional tests are a great asset in your quality assurance arsenal because they add to the confidence you have in your system and you will catch yet more bugs early. Unit test- and integration tests are nice and necessary, but I think they are subservient to the result of functional tests which finally determine the quality of the system.
Functional tests don’t replace manual testing
Very complex scenario’s may be quite hard (e.g. expensive) to automate, so it’s probably best you leave those to your testing team. The best candidates for automating are:
- scenario that cover notoriously buggy bits of functionality
- simple scenario’s that are mind-numbing to test for the testing team
Talk to your testers and decide together which scenarios you want to automate. They will know.
Geb is great
I scanned the functional testing tool framework landscape, and Selenium quickly emerged. Using Selenium IDE is not an option if you want to have a maintainable, robust test suite. Looking onwards, writing Selenium tests in Java didn’t really appeal to me either. Another tricky API to learn, lots of Java to write… until I found Geb. In essence, Geb is a Groovy DSL for telling a browser what to do. It is built on top of Selenium. Until now, Geb isn’t very well-known but there is no reason why that shouldn’t change quickly. The Spock/Gradle/Geb sample is where I got started.
Geb creates screenshots and html dumps of every test it runs, to speed op diagnosing tests that have failed. It plays nicely with Hudson / Jenkins in a sense that it reports test results in jUnit style. What you will need to do is setup a Windows box as the machine that runs all your tests. If your application has a history of suffering from bugs that occur in one browser but not in another, you will want to run the tests in different browsers, probably including Internet Explorer. Since it allows installing all major browsers, a Windows box is a natural choice. On that box you configure a Jenkins slave (through Java Web Start) that kicks off the tests.
Running automatically is tricky
You’ll need to have some mechanism in place that resets your system under test to a default state before a test runs. This is harder to do than with unit tests: you’ll have to clear databases, messages queues and whatever other resources your system uses. This will take time. Make sure you take this into account before putting a lot of effort into developing functional tests.
Functional tests take time to run
Unlike unit tests, which are very quick, functional tests are actual user scenario’s, so they can take quite some time to run. This can become a real issue when you have a lot of tests. So keep this in mind when you add tests and when you decide which scenarios to automate. Maybe you’ll need to split them up further, maybe you need to adjust the granularity of your scenario. It all depends
Mix in other types of system clients
This post focusses on giving input to the system through a browser, but there is no reason why your Geb-based test can not also talk to some kind of webservice that your system exposes. As long as the scenario is realistic, it is valid. What is not valid is to peek inside your system’s database to check for result. The rule is: if the system doesn’t allow a user (including machine clients) to do it, you can’t do it in your test. That would dilute the value of your test.
The end result
Me and the team on my project added about 50 tests for a system we were having trouble with to get under control. Geb allowed us to that quite quickly. I did some pioneering myself, and after that it was quite easy to get other team members on board. Soon enough, everyone was coding tests for scenarios they knew needed to be automated. After a few weeks of the test suite showing up as green in Jenkins (or blue if you’re unfortunate enought not to have the Green Balls plugin), the project had left the rough seas it had been in. For us, that was a big win