Test automation framework: why you should have one
In software development it’s hard to find anyone who considers software architecture useless, the same applies to automation testing. By test architecture I mean all code that will support and facilitate test cases development and execution (e.g. test framework), the project structure and any management that will take place (e.g. test data management and documentation).
First of all there are 3 key points that reveal test automation framework uses:
- Code support
- Test support
- Analysis
Analysis plays an important role for code support as well as test support – it is the most customer-oriented part, tightly connected with framework. Now let’s take a look at automation project architecture where test framework takes place.
- System under test is processed with test tools through application interfaces (GUI/API)
- Test tools actions and test libraries methods are invoked through its API by test framework.
- Test framework uses test data, usually specially formatted for it.
This is the most common architecture. But is test framework really helpful?
First of all – forget about linear tests. Implementing test libraries makes your code reusable. Why doing same things over and over again when you can simply implement it once and use several times?
Main idea of test framework: a little bit more efforts once – much less efforts each time later. A common solution for this is design patterns. With design patterns we can improve some tests capabilities.
For example Page Object pattern reduces the maintenance impact, helps to implement similar tests much easier. In web testing Singleton can be used to provide a driver instance to tests instead of inheritance. If you need to verify a database, the Entity can be used to reduce the quantity of database connections.
However using design patterns along with test framework is recommended, but not obligatory.
When you need to decide what architecture to choose and answer the question “Should we have test automation framework?” try first to answer on this questions:
- Who will develop the tests and analyze results?
- Does this person have the right technical skills and domain knowledge?
- Do you need to separate test description and/or data from low-level code?
- How many third-party tools you use to access SUT?
- Do you have time and budget to implement it internally or it would be better to get a professional help?
The article is prepared by Yan Gabis