NGABannerNew1.png

DETAILED READ SECTION

Learn Framework Design Best Practices



Here are 23 best framework design practices which can be bring in action by any automation engineer while designing test automation framework for his assigned projects:


1. Configurability

Configurable items like application, url, versions, paths, ip’s, etc. of a script should be kept in an external file. Once deployed to a system, no manual configuration changes should be required and scripts should automatically configure the required settings.


2. Setup Information

Any kind of setup should be done by the @Before method, or some similar annotations.

So the framework being used will know these actions need to be executed before performing the automated tests.


Information examples: type of browser, which URL should be opened, which timeout should be respected, should the browser be maximized or not and so on.


3. Test Folder and Source Folder


All Test classes should be saved inside a folder called “test” and it MUST be a kind of mirror of the source folder, meaning it will follow the same structure of the main project folder, but it will only contain tests.


For example:

Main source folder = Project A > Sanity > src > main > java

Main test folder = Project A > Sanity > src > test > java


4. Maintain Object identification repository


Most common issues faced during automation are object identification changes. Framework should be able to patch such changes easily.


This can be achieved by storing all object identification settings at a shared location in the form of external XML file, excel file, database or automation proprietary format.


5. Status monitoring using debug logs and Exception Handling


A framework should allow monitoring of the execution status in real time and should be capable of sending alerts in case of failure using exception handling. This ensures quick turnaround time in event of a failure.


6. Reporting


The framework should support html/Excel/Pdf report formats with details about test pass/fail for each test case/suite/test run.


7. Test Scripts and Test Data


Test scripts and test data should always be separated from each other. Test data input can be in various forms like XML, Json, Excel, text files, database inputs, hash maps etc.


8. Libraries


A library should contain all reusable components and external connections such as databases, generic functions, application functions etc. Tests should be exposed only to the implemented libraries and tests should be performed by invoking these libraries


9. Performance impacts


A framework should also consider the performance impacts of the implementation. Techniques like compiling all code into single library / dll while execution, no hard sleeps etc. should be used to improve performance whenever possible.


10. Script/Framework Versioning


<