Supercharging Your Test Automation
Many companies already have an open-source test automation solution in place. But many of them know they’re not getting the most out of it.
Sometimes it’s due to high maintenance. Sometimes it’s how fast tests get created. Other times it’s a limited number of people who can write the tests.
If some, or all, of those sound like your team, then this post is for you! Refreshing your automation is much cheaper than a rewrite. And enhancing in-house frameworks is a key service that Arch DevOps provides.
Here are some of the ways that happens:
Cucumber
Cucumber is in a popular class of tools called “Behavior Driven Development”, or BDD. It adds a flexible layer of English on top of your test code to make building tests easier and faster.
The reasons for this are readability and reach. Without it, each test exists as raw code. The only people who would understand it are developers or automation engineers. It’s not as readable.
With it, the tests are not only readable but more people can write them. This is where the reach gets longer. While we may not know the programming language, we all know English.
That means, instead of writing tests with code, like this:
$b.text_field(:xpath => "//input[@id='username']).set("myname")
$b.text_field(:xpath => "//input[@id='password']).set("password")
$b.element(:xpath => "//div[text()="Login"]).click
assert $b.element(:xpath => "//h2").text() == "Home"
Your tests get written like this:
When I enter "myname" into the "username" field
And I enter "password" into the "password" field
And I click the "Login" button
Then I should be on the "Home" page
Regular Expressions
As powerful as Cucumber is, many frameworks suffer a common problem. Test steps get written that only have slight differences.
Here’s an example:
When I click the "Submit" button When I click on the "Submit" button When I have clicked the "Submit" button
The differences here are cosmetic. But this is exactly the type of thing that slows people down.
As they write a new test, either they’ll sit and wonder: “Was it ‘the’ or ‘on the’?” Or, “Was it supposed to be present tense or past tense?” Or they’ll go look around in the code. Or worse, they’ll write another near-identical test step. This takes the focus away from what’s important. It also spends it on things that increase maintenance later on.
Instead, the underlying test steps get made as flexible as possible, using Regular Expressions:
When(/I (?:click|have clicked) (?:the|on the) "(.*)" button$/)
Past tense? Present tense? ‘the’ or ‘on the’? Doesn’t matter. Now you can spend less time thinking about that, and more on your application.
Granular Test Steps
Many frameworks also have complex test steps, that do a bunch of things:
Given I create a customer record
Although this is quick to write, it can be difficult to maintain. It can also be confusing to reproduce issues later. What goes into this customer record, for example? It’s not obvious from looking at this.
But breaking this out into pieces helps in many ways. Have a look at this example:
(...)
When I enter "Joe" into the "First Name" field
And I select "Male" from the "Gender" dropdown
And I enter "1000 Anywhere Dr." in the "Address" field
And I select "Software Tester" from the "Profession" dropdown
And I click the "Submit" button
(...)
Now it’s much clearer what creating a customer record means. It also means if a test fails, you can hand that text to someone so they know how to reproduce the failure. Smart.
Smart Waits
Speaking of smart: The most common reason tests fail or become slow is due to waits. Some automation will wait a set amount of time for an event. Some won’t wait long enough.
Tests that fail for either reason slow you down and steal focus from what’s important. As part of an effort, smarter logic gets put around wait times. This ensures much fewer false failures, and gives test suites a performance boost.
If any of this applies, Arch DevOps can help supercharge your automation. Set up a 15 minute discovery call here