A QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljkn.
Because UI tests are inherently slow, running them in parallel–that is, running multiple tests, in multiple browsers concurrently–is all but a necessity.
Luckily, it’s hilariously easy to run Geb tests in parallel, using Maven… all you need do is add the following code to you Maven pom.xml:
And then run your tests via Maven. Eg.
mvn test -Dgeb.env=chrome . You can try it for yourself by running my geb-example on GitHub.
This code will spread your tests between up to 4 threads/forks and run tests at the method (test) level. You can also swap out “methods” for “classes” if you’re prefer to run at the spec (class) level. Either way, you can dramatically speed up your automated tests with a few lines of code…
You did think about running tests in parallel when writing your tests… didn’t you?
Dave Thomas (PragDave) has an interesting post regarding the use of the word “Agile”. In it, he argues against the use of “agile” as a noun, preferring using “agility”… fair enough… but like the context driven folks, who would have us use the phrase “automated checks” instead of “automated tests”, I don’t really care. The argument itself may be interesting, but semantic change is a bitch; good luck!
But he also talks about “How to do something in an agile fashion”… which I found most intriguing:
What to do:
• Find out where you are
• Take a small step towards your goal
• Adjust your understanding based on what you learned
How to do it:
When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.
I love the simplicity of this. Additionally, he also states:
“…anyone who comes up with something bigger or more complex is just trying to sell you something.”
Nice work, sir… and for that, I changed my tagline to aid your cause :)
When I’m finally in charge, two of my first mandates will be: If you’re driving in the left lane, BE passing. But only slightly less important will be: “Please read Mythical Man Month”.
And you don’t even have to read the book if you don’t want. Simply read the Wiki page about the book and believe it. In fact, you can skip the book and the Wiki page if you’ll repeat the following three times, out loud:
“Adding manpower to a late software project makes it later”.
You may now become a manager…
There’s a veritable plethora of blogs, articles and papers, listing the mistakes commonly made when creating functional/ui automation… and many of these, themselves, contain common mistakes. Here’s one I recently found…
From an article “Five Common Mistakes and Their Solutions” by Artem Nahornyy:
Starting at the Wrong Time
It is a common mistake to begin test automation development too early, because the benefits almost never justify the losses of efforts for redevelopment of test automation scripts after the functionality of the application changes until the end of iteration…
During the development phase, members of a quality assurance (QA) team should spend more time creating detailed manual test cases suitable for the test automation…
Mr. Nahornyy argues that automating too early can waste efforts due to change, but the same argument can be made against his solution. Changes can also lead to waste when writing detailed manual test cases, early in development.
My advice is to start automating as soon as you can. For example, you might write automation code when devs are writing app code. Start with a failing test, and flesh out any page objects needed (or create them if they don’t exist). Then create any methods and/or data needed by the tests. This will save time later for manual/exploratory testing, when the code is complete.
Truth is, I would generally argue that it’s a mistake to automate too late, rather than too early. The ability to run even the simplest automated tests during a release can add real value. Kicking the can down the road with automation might at best, bloat your backlog, and at worst, never come to be.