Test automation framework architecture. Part 1 - No architecture

Most of the "UI test automation" tutorials I have seen describe the Test Automation Solution where Selenium Web Driver is used directly from test methods and no additional abstraction layer exists. This "architectural pattern" is so ubiquities, that I decided to describe this as well.

I think, we can call this "architectural pattern" as No architecture. The structure of test automation solution created with No architecture pattern presented (in a very rough way) on the picture below:


Such test automation solution usually consists of some amount of test classes, each containing some number of test methods. All orchestration of interaction with System Under Test (SUT) is done either (using JUnit terms) in setUp and tearDown methods, or test methods themelves. Tool, whatever it is - Selenium, RestAssured, Selenide - called directly in test methods.

Such approach is industy well known anti-pattern. However, in some cases, it may be ok to use. There're some benefits:
  • As no abstraction layers exists such tests are fairly easy (and fast) to create
  • As all code exists in one place it is fairly easy to understand what is going on
Those benefits has their price though:
  • Should you consider moving from one tool (lets say Selenium) to the other (lets say Selenide) you will have to update all tests you have
  • Should your UI (Web API) change slightly (id update, url update), all tests touching this UI (Web API) should be updated
  • Tests are not communicating well what they are testing, but very verbose on details how they test
  • Most likely there going to be lots of code duplications between test methods
Long story short - maintainability is screwed and visibility is ruined.

Nonetheless, if your plan is to add simple sanity check for a stable legacy system (and you are not going to have more than, lets say, 30 test cases), this may be a reasonable way to go.

If not, stay tuned - in next parts we will move into industry de-facto standard, Layered architecture.


Comments

Post a Comment

Popular posts from this blog

Test automation framework - do I need it at all?

Image
While there're lots of information published on the internet about how one should develop/buy a Test Automation solution, there's an elephant in the room - which is the fundamental question "Do I need to do it at all?". That is a good question. While I think that there’re some legitimate contexts where product/project/team can benefit from having a sophisticated test automation solution/framework, my general rule of thumb is “If you need a framework - you do it wrong” . There’re at least several decent papers showing the benefit of unit-testing ([1],[2], [3]), while I could not find any research proving that system level tests could bring better results. Please let me know if you can prove me wrong. There’s at least one half-scientific paper showing the benefits of unit tests in comparison to integration/system level tests [4] There’s a good paper bringing a notion of running/writing and maintaining test vs. the benefit of having/running it at...
Read more

Efficient test automation - Secret #1 | Test Club

Image
It seems everyone talks about efficient test automation, but not so many people have actually seen it! To cover this I decided to make several videos regarding the secrets of efficient test automation. Today we will talk about the first (and, arguably, the main) secret - realistic expectations. Very often, test automation projects or initiatives are started with the following unrealistic expectations: "Test automation will replace 'manual' testing" "Test automation will provide fast results and benefits" "Test automation efficiency depends solely on test automation engineers" Unfortunately, all those expectations are not realistic! Watch the video to know more!
Read more

An alternative to ubiquitous UI-level checking - Subcutaneous tests

Image
Let's assume a hypothetical situation - you were assigned to a project to help with the "test automation" initiative. You have a huge "test plan" as an input, containing hundreds (if not thousands) of "test cases" and you need to do something about it, quick. Problem statement Your first urge (if it is a Web application) may be to write some UI-level automated checks using tools like, you know, Selenium. In fact, there's a huge demand for such "Selenium test automators" in the industry these days. But please, please, don't do this. There're lots of things which make UI-level automated checking the least desirable approach: UI-level automated checks will be slow. There's just no way to avoid it. You can parallel them or do some other tweaks to speed them up somehow, but they still will be slow. UI-level automated checks will be flaky. Partly - because they're slow. Partly because Web browser and UI interface w...
Read more