Test automation framework architecture. Preface.

Some time ago I wrote this post describing my understanding (at that time) of the architectures used to create test automation solution (framework). While there's some information I still agree with, my understanding has evolved and I want to share this understanding with others.

First, lets probably coin the terminology I use (which is not necessarily would be the right one - feel free to suggest something different)

Test automation framework
It is a framework that allows one to write automated tests. Usually one means the specialized framework, i.e. framework that is specialized for one or several related applications under test. A framework does not include tests themselves

Test automation solution
It is is a complete solution used for test automation. It includes everything needed to perform the automated tests, including tests themselves. A solution may be based on a framework, however, it is not mandatory.

Architecture
May be described as an imaginary model that dictates how the code of the framework/solution is structured and communicates between parts. Usually, architecture is enforced by the physical distribution of code parts, but not always.

Once I was asked why we need an architecture. For me, it was that obvious so I couldn't even articulate this properly. Among other things, we use architecture to achieve these two things.

Increase maintainability
First, we need to divide code parts that change often from those which change rarely. It also has a nice implication that understanding which parts are going to be changing fast influences your architecture choices. Also, breaking things into parts allows the user to change them with a better sense of safety

Decrease complexity
The other thing is that dividing code into simple, digestible parts increases maintainability through simplification of things for the one who works on the code.

Most prominent test automation framework architecture types
  • No architecture
  • Layered
  • Layered pluggable
  • Hexagonal
  • Event-driven
I will describe each of them in the following posts, stay tuned and fill free to follow me on twitter!





    Comments

    1. Nice one. Please update me for the next post. Also if you can guide on hybrid framework implementation steps to be followed it would be great.

      ReplyDelete
      Replies
      1. Hello Ayan, I am glad that was helpful.

        I will do my best to get in touch when next part is ready. You can also try to connect to my LinkedIn profile or Follow me on twitter - I will definitely share new posts in my feed there.

        Delete
      2. Cool, thx! Waiting for further ones. My be described - typo, please fix.

        Delete
      3. Nice catch, fixed, thank you!

        Delete

    Post a Comment

    Popular posts from this blog

    Test automation framework - do I need it at all?

    Efficient test automation - Secret #1 | Test Club

    An alternative to ubiquitous UI-level checking - Subcutaneous tests