/** * The main template file * * This is the most generic template file in a WordPress theme * and one of the two required files for a theme (the other being style.css). * It is used to display a page when nothing more specific matches a query. * E.g., it puts together the home page when no home.php file exists. * * @link https://developer.wordpress.org/themes/basics/template-hierarchy/ * * @package WordPress * @subpackage Tally * @since 1.0.0 */ ?>
A testing automation framework is an execution environment for automated tests. Here are some of the points that will help you design an effective framework. I am keeping it generic so that it can be in implemented in any kind of product.
Keeping the script and data separate will help you in making a clean and non-redundant framework. So, always keep the data and script separate before designing a framework.
Let’s take an example of a simple selenium script and check how data abstraction can make the code clean and easy to maintain.
In the above example, XPATH is kept in the code. Now imagine you are using this XPATH at 100 places, and the XPATH is changed. This will take time to search all the code and change the XPATH.
Now let’s implement abstraction and check how this can help the Automation engineer.
In the above example, we have a separate file to keep the XPATH. In case anything changes, only one place needs to be updated i.e. login.py and all other test files will get updated.
Never ever ignore this, a successful framework can only be developed when you follow correct norms. Now these norms are also depended on the programming language you choose.
Your framework should not break if the test cases are increased or decreased. Instead, design it in a way that it should be able to upscale and downscale with minimum effort.
You must document how your framework works which includes internal and external documentation i.e. comment wherever possible and create a doc or a git wiki about how to use the framework.
Bad examples of documentation
The above code is tough to understand due to a lack of proper comments. A good code should have relevant comments for a person to code. Remember it is always not you who will use the code; always keep in mind that anyone who checks your code should be able to understand through comments.
A good example of internal documentation
In the above example we have written comment to show what the method does.
Make a separate library or a file in which you should maintain the methods which will be used again and again rather than creating separate methods. This will remove redundant methods and code.
To avoid duplicate code and redundant effort, we can maintain common reusable code (common git repository) across projects.
For Example, Report Integration, Email Notification, Loggers, etc.
are common for all automation projects. we can keep these in a single repository and reuse them across all other internal sub-projects.
* Write once reuse across
* Save time and effort
* One point control for common utilities of all the sub-projects
* Easy to integrate with new sub-projects
Always keep your framework updated – this can be achieved by regularly updating your API versions in the framework, if there is a change.
Logs Logs Logs …
Log as many things as you can – this includes logging pass/fail cases, additional information or errors. It useless to sit and stare at the screen for monitoring the cases, let logs do the magic.
Always have good exception handling its dirty if something like this shows, so handle as many exceptions as possible:
I hope this helps you to create an effective framework you can always comment and let me know if I have missed anything.
Best Way to Manage Books of Accounts When You Have Multiple GST Registration (GSTIN)