After the blog post here, we asked Rahul Verma if we could publish our solution on this blog. We were concerned about the same problem given in future contests. After getting a go-ahead, we are here to publish and describe our solution. The application for this contest was “WordPress”. There were three scenarios to be automated within three hours. One of the main requirements was that these scenarios should run unattended.
Scenario 1: Publish five unique blog posts. Verify that the blog posts have been published successfully.
Scenario 2: Create a user and login with the created user.
Scenario 3: Search for a particular post and delete the blog post.
We used Sahi Pro to automate these scenarios. We followed what we recommend to our users:
– Record with Accessor Repository enabled and create snippets of code
– Extract functions and use functions library
– Create Scenario files (.s.csv)
– Keep the data external to the script and call the file when required
– Club the scenario files into data driven suite (.dd.csv )
– Added tags for each scenario
– Execute .dd.csv from ant target
So, the final .dd.csv file is as follows:
Here, we are running three scenario files and tagged these scenarios with tags – all and scn1/scn2/scn3.
The scenario file for the first scenario is as follows:
We are logging in to the application and adding five unique blog posts. Once the posts are posted, we are verifying and finally logout of the application.
Let me describe the components of a scenario file here.
The first line of a scenario file is the column header – TestCase, Key Word, Argument 1, 2.
loadSahi loads the Sahi script with required function definitions. In this case, we are loading ‘blogARBlog.sah’ and ‘createBlogPost.sah’. blogARBlog.sah is the Accessor Repository file which we will know in detail later.
We are reading the data from an external file. In this case, it is a CSV file. So, we are using the _readCSVFile API
[Documentation] is useful for documentation purposes. One can note the purpose of the test case here.
In the [Data] [data:Posts:title] [data:Posts:content] [data:Posts:title], we are reading the data from the Posts.csv as per the column headings.
The other keywords are functions – login, addPostsAndVerify, logout.
As per our recommendation to our users, we also extracted functions and saved it in a separate functions library file.
The functions library file and the first script file is as follows:
We also used the Accessor Repository file in our scripts. This prevents the same element from being identified in multiple ways in different scripts. If there are changes expected in the element’s accessor, we need to update at only one place – the Accessor Repository (AR) file and all the scripts which include the AR file will be updated. This saves a lot of time and effort. The AR file for the first scenario is as follows:
And to identify the elements, we used our powerful recorder and object identifier which works on any modern browser. Once we ran the scenarios, the logs were automatically generated.
Finally, we generated the Ant Target and added to build.xml, configured Jenkins and ran the ant command from the command line.
Some of the unique features of our approach:
- We did not use any waits throughout the whole exercise. Sahi Pro automatically waits for the whole page to load. It also waits for all the AJAX activities to complete. One need not add any explicit wait.
- The use of relational APIs like _near which ensures that the elements are identified in relation to an element we are sure of, which will not change its position.
- We recorded on one browser and without any change in the script, we can play it back across browsers. We could also do a parallel playback using Sahi Pro.
- Sahi Pro came up with the reports after playback without us writing any extra code.
You can download the code for the whole exercise here: stepin
If you also used Sahi Pro in the competition and followed a different approach, feel free to share your approach with us. Hope you liked our solution. Till next time, happy testing with Sahi Pro!