You should always be careful about how you design / architect your test automation project , it is completely dependent on the size, nature & application landscape to test for a given project, you should make sure it is:
- Easy to create new automation scripts, especially the E2E(End to End) automation scripts / functional scenarios.
- Easy to maintain automation scripts.
- Ability to scale to new needs of the automation project with less changes to the architecture / design of the automation project related framework.
- Easy to execute the scripts.
It is a well known fact that in order to attain high re-usability in test automation projects, automation engineers create framework in such a way the reusable bits and pieces or components are created as scripts, so that they can be called when ever required.
Lets pick a real time scenario and understand more details, for example in your project you have 100’s of scripts which are spread across different functional modules of your application, these scripts could be grouped in combinations to create multiple End to End business flows or functional scenarios to test.
Following are the 3 reasons why you should call child scripts at run time
- Performance hit: For most of the test automation tools, if more number of scripts are associated as child scripts upfront to a master or parent script, the performance of the automation tool degrades when executing the scripts. This is due to heavy loading of scripts before initiating the script execution, it is always good to have a light weight script for realizing the full benefits of any test automation tools.
- Delay in creating new automation scenarios: When you create different master / parent scripts(i.e. an End to End functional script / functional scenarios) for above situation, it is not user friendly at all and time consuming to manually associate all scripts as child scripts to each parent / master script.
- Heavy script maintenance: If you have to modify any existing master / parent script by adding a new script, you have to open all E2E master scripts where there is a need and you have to manually associate the new script and add a statement to execute the new script. This will be a night mare for any automation engineer and there is a high chances of missing or making mistakes while changing the code.
The above 3 reasons explained are quite prominent in any test automation project and the best way to deal with this is by calling scripts dynamically or at run time, some of the test automation tools give inbuilt API or options to call the scripts at run time and some might give options to dynamically associate required scripts before executing the actual scripts.
You will have to thoroughly understand the underlying test automation tool and use the features or alternative approaches to attain dynamic calling of scripts at run time.
Founder of TestingTools.co, constantly shares knowledge on different test automation tools. Has experience in building proof of concepts, solutions, frameworks, platforms & implementation of test automation projects.
In pursuit of building a platform with inbuilt framework and reusable components for Oracle Cloud applications ( Oracle HCM, CX, SCM, Financials clouds, Salesforce and other cloud applications )
Major accomplishments in his career:
- Product architect and development manager for test automation platforms
- Oracle Flow Builder @ Oracle
- CloudTestr @ Suneratech
- 2 times to oracle open world
- More than 20 successful POCs ( Proof of concepts )
- 100 demos
- Designed pricing models.
- Trained more than 50 members.
- Built more than 100 re-usable functions.
Worked with tools: