Test automation framework architecture. Part 2 - Layered architecture
Probably the most popular architecture pattern used for test automation frameworks (TAF) is layered architecture. This pattern is so well known that on job interviews for some companies when they ask you about TAF architecture you are supposed to describe this one. If you don't - they think you know nothing about the architecture altogether.
I suggest you first read a brilliant description of the pattern at the O'Reilly web page, cause in this post I am going to describe the pattern in a way it is usually applied to build test automation solution.
Usually, there're three distinct layers, which may have different names, but follow the same logic mostly. Sometimes those layers called test layer, business-layer and core layer, but there're no standard names really. Key rules for layered architecture are the dependency direction (each level depending on the level below) and call direction (no level can call/reference code described in the level above).
The rough structure of such framework is shown in the picture below (notice arrows that indicate dependency/call direction).
Stay tuned - in next parts we will move into emerging industry wanna-be standard - Hexagonal architecture.
Follow @aqaguy
I suggest you first read a brilliant description of the pattern at the O'Reilly web page, cause in this post I am going to describe the pattern in a way it is usually applied to build test automation solution.
Usually, there're three distinct layers, which may have different names, but follow the same logic mostly. Sometimes those layers called test layer, business-layer and core layer, but there're no standard names really. Key rules for layered architecture are the dependency direction (each level depending on the level below) and call direction (no level can call/reference code described in the level above).
The rough structure of such framework is shown in the picture below (notice arrows that indicate dependency/call direction).
In such architecture, test layer typically contains test scenarios. They may be written in a programming language or DSL (like Gherkin in BDD inspired solutions). The key requirement for this layer would be:
- Test scenarios communicate test intention, not implementation
- Test scenarios structured in a way it doesn't takes ages to find a test for specific feature
Business layer provides a system under test (SuT) specific actions. For example, if we’re talking about online shopping, such actions may be to log in, add something to cart, e.t.c. This layer is a glue, mediator that allows translating complicated interaction with the SuT to high level actions, that will be used by test layer.
Core layer deals with orchestration, reporting and usually also provides low-level API to communicate with the tested application itself, like web-service facades, Selenium Web Driver wrappers, e.t.c.
In a BDD inspired framework, test layer will typically contain feature files, business layer will contain steps definitions, while core layer contains BDD-framework configuration and core components. For a data-driven framework, test layer will contain data files while business layer will contain mid-level application specific abstractions.
Those, who read preface for this series will probably notice the conflict with test automation framework given there (hint: framework does not include tests). I think this is historical heritage in our industry, where terms test automation solution and test automation framework were considered to mean the same thing.
From my perspective, it would be better to tell that framework consists of two layers (Business and Core layers), while test layer is just using a framework to provide fully-fledged test automation solution. Anyway, this is more of semantics question.
Follow @aqaguy
Thank you for sharing this
ReplyDeleteHi Alexander
ReplyDeleteThank you for posting these blog entries. I'm having trouble wrapping my head around the Business Layer (doAction1) and the Core Layer (Application Facades). Can you please describe by example?
What do you think of this example and is the test invoking the business layer or the facade layer here?
@Test
public void testCreateAccount() throws Exception {
FooClient client = ClientFactory......
CreateAccountResult = client.createAccount(new CreateAccountRequest());
CreateAccountValidator........
}
Hello,
DeleteI think I shall do an example implementation in one of the following posts, please stay tuned!
From the code snippet it is difficult to say exactly, but I think that client is a some kind of facade that wraps system under test. If this is the case, t seems that there's no business layer and the test touches core layer. Is good or bad depends on the use case - sometimes it is not necessary to distinguish business layer, especially if system we are testing is simple enough.
Hope this helps!
Alex.
Hi Alexander - do you still plan to do an example implementation?
ReplyDeleteI'm looking forward to it & thank you!
Scott W
Hello Scott! I think I should do an example implementation before working on any other post. The problem is that I can think at last of two examples to work on - "usual" framework and framework that uses BDD-inspired tools such as JBehave. What do you want me to start from?
DeleteTechsaga Corporations is an Operational automation strategy makers company. The benefits of automation create expectations for customers, stakeholders, and employees; the effectiveness of automation allows us to maintain them. As IT environments increase in complexity and the amount of data, devices, systems, and platforms expand.
ReplyDeleteIT's very informative blog and useful article thank you for sharing with us , keep posting learn more about Product engineering services | Product engineering solutions.
ReplyDelete