Lets set the scene
So, there you are… having a UI and an entire suite of manual test cases. These tests are tedious, take forever and lets be honest…can get repetitive and boring!
My friend, you are in the frontline for automating your testing!
Tools
Lets not beat around the bush – Selenium has been around for ages. The product has had millions of users, has become a W3 standard and is launching selenium 4 pretty soon.
This is the tool for us.
There are others yes, most of which will wrap some selenium WebDriver capability into a pretty package and sell you that at a pretty penny.
Lets not get the wool pull over our eyes.
We can do the same, implement at the same level and in fact, have far greater control on our test product ….cheaper, faster, better.
Ok, before we get butterflies in our tummies over this tool, there are some pitfalls…urhgggg, of course.
Not to worry, we have help – in our demo below, I will show you how I implemented Selenide – an open source project to fill the gaps that were obvious in Selenium 3.
You can read up on the tools here:
Selenium
https://selenium.dev/downloads/
Selenide
A wrapper around selenium with a few more fluent apis for us to work with. therefore, it is my. preferred library.
Show me the baby trees(bacon is nice but baby trees are better)
Head on over to my github page and you will find a FEW implementations of UI testing,
https://github.com/suveerprithipal to find this code and more. Dont limit yourself. There are many ways of implementing this.
Here is one I’ve taken from https://github.com/suveerprithipal/selenideJava which implements Selenide.
https://github.com/suveerprithipal/selenideJava/blob/master/README.md
* @author Suveer Prithipal
public class GoogleTest {
@Test
public void googlePageTest(){
/**
No need to create a webdriver instance!
Selenide provides with easy to use API's that provide rich functionality.
On a normal day with selenium, we would need to create a webdriver instance, and bind it to a browser.
We would also need to define page elements to use them.
Selenide removes the need to do this by wrapping up that into a singe API.
Below, we use "open" to create the webdriver instance, and bind it to a class.
Passing it a class, provides the shape for the instance, giving it methods and defined functionality.
*/
GooglePage googlePage = open("http://www.google.com",GooglePage.class);
/**
Now that we have an instance of webdriver up and we are on our test app, Google.
We can then search something.
Searching for something means it will return a result.
Therefore, we need a class to take the shape of these results.
*/
SearchResultsPage searchResultsPage = googlePage.searchGoogle("selenide");
/**
Tests.
Now that we have results, we can perform tests.
Below, we use the searchResultsPage and query the class for expected results.
*/
searchResultsPage.checkResultsSize(8);
searchResultsPage.getResults().get(0).shouldHave(text("Selenide: concise UI tests in Java"));
/**
Use page object models and design patterns
This example is to demo the ease of use with Selenide.
Its important to separate out your implementation for better maintenance, easy of reading and debugging.
*/
}
}In Code – Get going in 3 easy steps
This project is written in Java, uses the page object model and is triggered by a BDD Cucumber feature file. Learn these terms well.
Lets get into it:
Step 1: Define our Page Objects
The things you want to interact with on a page like:
- buttons
- lists
- labels
- text inputs
Step 2: Step Definition
Step definitions are the glue that will bring a workflow to your elements and bind them your feature file.
Here we chain our actions together and feed them input using our feature file.
Eg, the loginCuke() method:
- we open up the site in a web page using Selenide. A 1 liner which will handle a lot of the grunt of selenium behind the scenes.
- we then proceed to run the login method that will:
- take our input username and password from the feature file and process the login method.
Step 3: Create your feature file
Feature files are BDD scribed tests.
We write these in plain english and translate that to code…as we did above
Thats it! run your feature file and wait for the results.
You’ll see the browser opening and doing things. Screenshots are a default on failure with Selenide so you’ll have that too!
Reporting:
Reporting is a must in any project. Please have a look at my other content for more details or pursue your own.
Conclusion:
UI testing has been around for a while and is getting easier, cheaper and simpler to implement.
With the older versions selenium we had to code a lot to get a page to open, while today we can achieve this in 1 line with a very fluent api.
Write once, test 1000 times on all browsers
our tools allow us to test on all browsers and any version…. simultaneously.
A bless in the UI testing world as it allows us to drastically reduce our testing time and therefore our cost to service testing.
Writing our own frameworks gives us greater advantage in scale and capability.
Nothing is more fore-filling than overcoming a challenge by learning, trying and failing!
(The Random Tester) -> 