I am going to explain a tool that I created which stands in between Record and Play Selenese and robust automation code.
You better read my previous post to see why I came up with such a solution.
The purpose of the solution is
Bearing the above considerations in mind, I decided to go with a "hack-around of Selenium IDE."
The design had three layers
1. Action layer - containing all the actions. An action is the atomic element which performs a logical action and placed inside an action file.
2. Template layer - Template files are there just to contain action files, and other template files. They are similar to directories which contain files and other directories.
3. Data layer - Data files contain the data of a template file. Parameters of the template file, and the data file should exactly be the same. Data in the data files will be copied to templates, and then to action files.
Let me give three sample action files here. Name of the action is the name of that particular file.
Name of the action file: OpenURL
param:URL
<tr>
<td>open</td>
<td>#URL#</td>
<td></td>
</tr>
Name of the action file:TypeSearchItem
param:SearchItem
<tr>
<td>type</td>
<td>id=lst-ib</td>
<td>#SearchItem#</td>
</tr>
Name of the action file: ClickGoogleSearch
param:
<tr>
<td>clickAndWait</td>
<td>btnK</td>
<td></td>
</tr>
The below template file could hold the above action files.
Name of the template file: SearchGoogle
OpenURL URL
TypeSearchItem SearchItem
ClickGoogleSearch
Then I create a data file to hold the data of the above template. It would look like below.
param: URL SearchItem
google.com,mailtoirs.blogspot.com
google.com,orange
google.com,apple
If I run the tool, it will map the data file to template file, correctly replace the parameters in the action files and produce one selenese script which can search google for "mailtoirs.blogspot.com", "orange", and "apple", one after the other.
What I described so far is the essence, and a simplified view of the tool I created. The tool actually contained another layer, suite, which puts templates together and generate a selenium suite.
We got a project where the tool could be used immediately. The project was fairly complex, and the duration was 2-3 months. Myself and another new person, who was a fresher to the field, had to complete the manual testing as well as the automation within the duration of the project. The concept and tool became very handy, and with some struggling, we were able to successfully automate the product to a certain level.
I was hoping to automate the entire base product using the tool. But, as usual manual testing were prioritized, and I did not have a chance to automate for a while. Then, as days passed, the initial concerns and assumptions changed, and that paved the way to another technology to be used. Details will follow in the next post.
You better read my previous post to see why I came up with such a solution.
The purpose of the solution is
- the tool should be usable by non-technical people as well
- a single modification of the web application should break only a single unit in the automation suite. For example, if a text box is renamed in the application, it should be possible to fix it only in one place and correct the suite.
- should allow re-usability. i.e. We should be able to build a block of solid piece and reuse multiple times
- should support parameterizing the data.
- the learning curve should be small, and after that users should be writing test cases straight away without worrying much about building large frameworks.
Bearing the above considerations in mind, I decided to go with a "hack-around of Selenium IDE."
The design had three layers
1. Action layer - containing all the actions. An action is the atomic element which performs a logical action and placed inside an action file.
2. Template layer - Template files are there just to contain action files, and other template files. They are similar to directories which contain files and other directories.
3. Data layer - Data files contain the data of a template file. Parameters of the template file, and the data file should exactly be the same. Data in the data files will be copied to templates, and then to action files.
Let me give three sample action files here. Name of the action is the name of that particular file.
Name of the action file: OpenURL
param:URL
<tr>
<td>open</td>
<td>#URL#</td>
<td></td>
</tr>
Name of the action file:TypeSearchItem
param:SearchItem
<tr>
<td>type</td>
<td>id=lst-ib</td>
<td>#SearchItem#</td>
</tr>
Name of the action file: ClickGoogleSearch
param:
<tr>
<td>clickAndWait</td>
<td>btnK</td>
<td></td>
</tr>
The below template file could hold the above action files.
Name of the template file: SearchGoogle
param: URL SearchItem
OpenURL URL
TypeSearchItem SearchItem
ClickGoogleSearch
Then I create a data file to hold the data of the above template. It would look like below.
param: URL SearchItem
google.com,mailtoirs.blogspot.com
google.com,orange
google.com,apple
If I run the tool, it will map the data file to template file, correctly replace the parameters in the action files and produce one selenese script which can search google for "mailtoirs.blogspot.com", "orange", and "apple", one after the other.
- Action files are usually created by recording in the Selenium IDE, and then modifying it a bit for parameterizing, and saving as different files. Creating the above example took me less then 5 minutes.
- The final resulting selenese script is also run using the Selenium IDE.
- If google changed the name of the search box one day, I would have to rename it simply in one action file (TypeSearchItem), and run the tool to regenerate the selenese script. Had this been a manual recording, I would have to replace it in all three searches manually.
What I described so far is the essence, and a simplified view of the tool I created. The tool actually contained another layer, suite, which puts templates together and generate a selenium suite.
We got a project where the tool could be used immediately. The project was fairly complex, and the duration was 2-3 months. Myself and another new person, who was a fresher to the field, had to complete the manual testing as well as the automation within the duration of the project. The concept and tool became very handy, and with some struggling, we were able to successfully automate the product to a certain level.
I was hoping to automate the entire base product using the tool. But, as usual manual testing were prioritized, and I did not have a chance to automate for a while. Then, as days passed, the initial concerns and assumptions changed, and that paved the way to another technology to be used. Details will follow in the next post.
No comments:
Post a Comment