Things To Consider When Designing a UI Automation Framework

I feel it is essential to discuss the destination before we start the journey.  Before we write any line of code, we want to clarify how our software is going to be used by the end user (in this case, by the Automation Tester who will be writing scripts based on the framework.)

Here is an example of where we might want to get to:  Have a look at this snippet.

There are some interesting characteristics the snippet above has;

• You do not know which object oriented programming language was used to write the script (if you try to guess and you’d probably be right, it is csharp). The point here is, if we decide to switch the underlying framework language to java for whatever reason, our scripts need not change.
• You can guess what the script is trying to achieve i.e. what is being tested as the Method Name and the Test Steps give it away.
• You are able to gain knowledge of the steps and actions involved in using that particular function.
• You do not have a clue or any knowledge of the underlying driver that is driving UI.
• It looks beautiful.

DOMAIN SPECIFIC LANGUAGE

A Domain Specific Language (D.S.L) wraps selenium API implementation and steps as method calls from page objects. It provides a number of benefits some of which include;

Readability: In an agile world for example, the tester has a number of stakeholders including the Product owner, Developer, Test manager etc. it means anyone can look into the script and understand exactly what is being tested

Easy Scripting: Test Scripts becomes a lot easier to write from scratch. It also means scripting will not only be a skill limited to the automation tester as anyone could potentially write scripts to test the Application under test.

Re-usability: D.S.L promotes reuse of a script in multiple tests hence, unnecessary duplication is avoided especially when used in combination with Unit Testing Tools.

Extensible: Functionality can (reasonably) be added without breaking contracts and existing functionality.

Maintainable: By leaving the implementation details out of test cases and scripts, you are well-insulated against changes to the System under test

 Best Practices

There are many articles online from highly experienced individuals, and group of people, that suggest guidelines on how we can design a UI automation framework, and the project will not turn into maintenance nightmare. Here are few things we will consider and try to adhere to as we build a UI Automation framework.

1. We are going to design our framework using Page Object Model and a number of Design patterns and principles relevant to OOP language.
2. We are going to create an Internal DSL for Scripting
3. We will ensure assertions only be made in test scripts
4. Required browser will be passed in at runtime
5. We will avoid creation of Objects in Test scripts
6. We will hide every complexity within the framework
7. We will stick to maximum 3 parameters per method
8. We will Make Page Objects return Other Page Objects
9. Our framework will have reporting capability built in
10. Our framework will be Easy to maintain, reusable, scale-able and solid.
11. Our framework will be ready for Continuous Integration
12. Our framework will be very easy to deploy into multiple projects and will set itself up automatically (well, we might as well automate that too)
13. We will Automate the documentation where possible and provide manual for easy scripting
14. We will provide Logging functionality within the framework
15. We will provide capability to Pass in Data Externally during run-time
16. We are going to practice what we preach by testing the framework before release;
17. We are going to version control our framework code
18. We will provide ways to ensure tests are repeatable by ensuring they start and end from a known state of the Application under test

Not all of the list above is understandable right away, but as time goes on, when we get hands on, it will all be clearer, the reason and purpose of designing in this manner will become much more understandable.

Next topic, we will setup the Application we will be testing with. Click here  to be the first to know when it is published.

Any thoughts, questions, comments, addition, or anything you don’t like, do not hesitate to leave a comment or contact me. Thank you!

Further Reading:

http://martinfowler.com/bliki/PageObject.html

http://softeng.disi.unige.it/publications/2013-leotta-ICSTW.pdf

https://seleniumhq.github.io/docs/best.html#domain_specific_language