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 first reading brilliant description of the pattern at the oreilly 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 depend 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 on the picture below (notice arrows that indicate dependency/call direction).

In such architecture, test layer typically contains test scenarios. They may be written in programming language or DSL (like Gherkin in BDD inspired solutions). The key requirement for this layer would be:
  • Test scenarios communicates 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 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 to translate complicated interaction with the SuT to a 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 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 component. 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 same.

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 semantic question.

Stay tuned - in next parts we will move into emerging industry wonna-be standard - Hexagonal architecture.

Comments

  1. Hi Alexander

    Thank 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........
    }

    ReplyDelete
    Replies
    1. Hello,

      I 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.

      Delete

Post a Comment

Popular posts from this blog

Test automation framework architecture. Preface.

Test automation framework architecture. Part 1 - No architecture