Fiona Nic Dhonnacha

Jul 22 2022

Why attend AutomationSTAR

Why is AutomationSTAR an unmissable experience? This is where the leaders in software testing are coming together.

Accelerate your testing projects, make connections, & join a global community. This is a space to deep dive into all things automation in testing, and share different perspectives, discuss the problems and issues you face, and find solutions together. Check out everything that’s on offer, and join us in Munich, 17-18 Oct.

Valuable learnings

Whether you are new to coding, building a test automation project from scratch, or interested in codeless tools, AutomationSTAR is where you’ll find the answers. Our superstar speakers are bringing you answers, to help you accelerate your delivery, get future ready, and achieve your goals. Talks will cover different levels of automation in testing, including methodologies such as DevOps, new technologies like AI, and lots more

Meaningful connections

It’s a diverse community bursting with creativity – with plenty of chances to jump into different conversations and make meaningful connections. With coffee breaks, networking lunches, and lots of bonus sessions, AutomationSTAR is where creativity flourishes. You’ll chat with software testers from every industry, and have lots of lightbulb moments as you spark new ideas.

Expert speakers

25 speakers will bring you in-depth knowledge on everything automation – get razor sharp insights directly from testing leaders. Learn about the role of automation engineers, how to achieve reliable test automation, and answer questions on why we test and why we make the choices we do. Kickstart your cypress test automation, create an automation framework, learn the importance of soft skills, and LOTS more.

Solve testing challenges

We know that you’re looking for tangible results – that’s why our testing experts will be answering your tough questions, whether that’s during an inspiring track talk session, or an in-depth tutorial. The AutomationSTAR speakers will share their own experiences and learnings, to get you where you want to be in your test automation projects. You’ll also be surrounded by like-minded peers who are having the same issues you are, and finding solutions together.

Teamwork

We are all about the community, and we love welcoming teams to the conference. QA team training is crucial for implementing successful automation projects. Create a whole team approach at AutomationSTAR, ensuring everyone is well versed in their roles, and possess the technical skills they need to support the tests, scale productivity – and deliver an exceptional user experience. Bonus: groups save on tickets, so get the office together and join us in Munich.

Our 2-for-1 offer is currently running until July 31st – this is your chance to save 50% on tickets! Book now.

get tickets

This blog is translated from English to German by Google.

Jun 23 2022

Check out the AutomationSTAR Conference programme

Check out the AutomationSTAR programme, packed with inspiring sessions and in-depth tutorials, to elevate your test automation projects.

The AutomationSTAR programme is live! This October 17-18, the sharpest minds in automation are coming together to share their knowledge with you. Through visionary keynotes, track talks, workshops, and half day tutorials they will share new insights, real-life experiences, and help YOU with challenges in your testing projects.

Whether you’re new to coding, building a test automation project from scratch, or interested in codeless tools, AutomationSTAR is where you’ll find the answers. Accelerate your delivery, get future ready, and achieve your goals. Talks will cover different levels of automation in testing, including methodologies such as DevOps, new technologies like AI, and lots more.

World class keynote speakers

Our inspiring keynote speakers are bringing you top insights on test automation. Bas Dijkstra questions the role of automation engineers, and why the role of test automation engineer is a difficult one. Andrew Knight discusses why testing itself is art as much as it’s engineering, and will give you a blueprint for testing success. Jenny Bramble strives to answer the question of why we test and why we make the choices we do.

Inspiring track talks

The AutomationSTAR track talks are packed with thought-provoking sessions – speakers will discuss a wide range of topics to add real value to your testing: how to get true success from automation, event driven test automation, how to make your automated tests reliable, revolutionizing your functional test automation, and lots more. Get ready to accelerate your projects.

Meaningful connections

Of course, you’ll also have plenty of opportunity to network with other delegates, and expand your connections. With coffee breaks, networking lunches, and lots more, AutomationSTAR is a diverse, collaborative environment where creativity flourishes. You’ll chat with software testers from every industry, and have lots of lightbulb moments as you spark new ideas together!

see programme

This blog is translated from English to German by Google.

Jun 22 2022

Selenium tutorial: How to handle popups with Selenium Webdriver

This article will dive deeper into how to handle popups with selenium webdriver, and how to automate them. This is a blog post provided by Mark Collin on EuroSTAR Huddle, our online community for free software testing resources.

Demystifying popups with Selenium

After you have been working with Selenium for a while you will eventually be given a task to automate something that has some sort of popup functionality. Popups can be a sticky subject in Selenium because the definition of what a popup is can be unclear and different drivers exhibit different default behaviour. In this article I will try and provide some clear definitions of different popups, show you how to handle Popup in Selenium Webdriver and show you how to automate them, and a few gotchas as well.

First of all we need to define what we mean by a popup; it’s a nebulous term that people use to describe multiple different types of functionality that is out in the wild. I like to put popups into three main categories:

OS level popups

The first popup listed is an OS level dialogue; these are the things you will see when the browser hands over control to the operating system to do a task for it (although browsers like chrome are blurring the lines here a little bit by making it look like the browser is doing it). You will commonly see these if you do something that the browser cannot do, at this point the browser will hand over to the OS to find another program to perform the required task. Some examples of these things are:

Printing a page you are viewing in the browser.
Sending a link as an email.
Downloading a file.

The best option to deal with these OS level popups, is to never do anything that will trigger them in your test. Selenium tutorial is only designed to interact with websites rendered in
the browser, controlling the OS is totally out of scope. If you did want to try and interact with these OS level popups you would need to write some code that can control the
OS itself (e.g. something using the Java Robot classes). There are tools out there that will do this, but it’s a complex bit of work and you really don’t need to test OS level functionality to check that your website works.

HTML popups (Lightboxes)

A HTML popup can look like a JavaScript popup, or a OS level popup, but in reality it’s just more HTML layered over the top of existing HTML on the website. Due to the fact that these popups are HTML website designers can use CSS to make these things look like something they are not, which can cause confusion. You don’t need to do anything special to work with these; after all they are just HTML and CSS. You just interact with them in same way that you would interact with any other element on screen and then do what you want.

JavaScript popups

These are blocking popups; they will pause JavaScript execution until they have been interacted with. Historically, these were the default type of Selenium popup, although nowadays they are not quite as common because website designers tend to prefer using non-blocking HTML popups instead. These are things that Selenium can interact with, but you will need to know what actions are going to trigger these popups in advance.

We should now have a clear idea in our mind of the various types of popup. Next, let’s have a look at some code.

Working with alerts

First of all, we are going to look at how to automate things alerts. To start with, we will need some HTML to automate. Save the following html as ‘alert.html’:

private String alertFileLocation = “file://<PATH_TO>/alert.html”;

<!doctype html>
    <html lang="en">
    <head>
        <title>Alerts in Selenium</title>
        <link rel="stylesheet" href="http://code.jquery.com/ui/1.12.1/themes/base/jquery-ui.css">
        <link rel="stylesheet" href="http://jqueryui.com/resources/demos/style.css">
        <script src="https://code.jquery.com/jquery-1.12.4.js"></script>
        <script src="https://code.jquery.com/ui/1.12.1/jquery-ui.js"></script>
        <script>
            function triggerAlert() {
                $('#alert').dialog();
            }
        </script>
    </head>
    <body style="background-color: #6cb5ff">
    <div id="buttons">
        <button id="js_alert" onclick="alert('This is a JavaScript Alert');">Click me for a basic JavaScript alert</button>
        <button id="html_alert" onclick="triggerAlert()">Click me for a basic jQuery alert</button>
    </div>
    <div id="alert" title="Dialog" style="display: none">
        <p>This is an alert box triggered by JavaScript, but rendered in rendered in HTML</p>
    </div>
    </body>
    </html>

This is a simple page that has a couple of buttons. One will trigger a HTML alert, and one will trigger a JavaScript alert. Load it up in the browser, and try it out to see how it works.

We are now going to write some code to automate this page. First of all, we need to define the location where you saved the above HTML. Just replace in the below code with the path to the file you saved above.

private String alertFileLocation = “file://<PATH_TO>/alert.html”;

Now on to our first basic piece of automation:

@Test
        public void triggerBothPopups() throws Exception {
            driver.get(alertFileLocation);

            WebElement generateAlertOne = driver.findElement(By.id("js_alert"));
            WebElement generateAlertTwo = driver.findElement(By.id("html_alert"));

            generateAlertOne.click();
            generateAlertTwo.click();
        }

This code will load up the web page: click on the button to trigger the JavaScript alert, and then click on the button to trigger the HTML alert. If you now run this test it should fail, and you should see an error that looks like this:

org.openqa.selenium.UnhandledAlertException: unexpected alert open: {Alert text : This is a JavaScript Alert}

However you may not have seen an error…

This is because different drivers are implemented differently; if you are running Firefox v53.0.3 and GeckoDriver v0.16.1 it will have ignored the fact that there is a popup there and tried to carry on regardless. We will come back and look at this later on. For now, let’s make sure we are using chromedriver.

Now that we are using chromedriver, let’s try and fix our automation code. Selenium provides an API that enables you to interact with alerts, so let’s use it.

   @Test
        public void triggerBothPopups() throws Exception {
            driver.get(alertFileLocation);
            WebElement generateAlertOne = driver.findElement(By.id("js_alert"));
            WebElement generateAlertTwo = driver.findElement(By.id("html_alert"));

            generateAlertOne.click();
            driver.switchTo().alert().accept();
            generateAlertTwo.click();
            driver.switchTo().alert().accept();
        }

As you can see, we are now telling Selenium to switch to the alert once it has popped up. Once we have switched to it, we are telling Selenium to accept it. Let’s run the test again and see what happens now.

You should now see the following error:

org.openqa.selenium.NoAlertPresentException: no alert open

This is because our first alert is a JavaScript popup, but our second one is a HTML popup (or a Lightbox). The functionality to switch to an alert and accept it will only work with JavaScript popups, not HTML popups. To interact with the HTML popup we will need to look at the markup, and deal with it like we would any other HTML element.

Here is our final bit of test code.

 @Test
        public void triggerBothPopups() throws Exception {
            driver.get(alertFileLocation);
            WebElement generateAlertOne = driver.findElement(By.id("js_alert"));
            WebElement generateAlertTwo = driver.findElement(By.id("html_alert"));

            generateAlertOne.click();
            driver.switchTo().alert().accept();

            generateAlertTwo.click();
            WebElement closeHtmlAlertButton = driver.findElement(By.cssSelector(".ui-button"));
            closeHtmlAlertButton.click();
        }

We are now treating each type of alert correctly, and we have one happy piece of automation.

Why the test didn’t fail in Firefox

Continuing with our Selenium tutorial, let’s go back to the problem with Firefox that we mentioned when we wrote our initial test. Firefox was not throwing an exception when an unexpected alert was present, so we weren’t seeing an error. If something like this happens it can be very confusing. The main reason our test was not failing was because we were not performing any checks after
interacting with the elements. Let’s take the final test that we wrote and delete the code that switches to the alert, and see what happens when we run it in Firefox v53.0.3 and GeckoDriver v0.16.1.

@Test
            public void triggerBothPopups() throws Exception {
            driver.get(alertFileLocation);
            WebElement generateAlertOne = driver.findElement(By.id("js_alert"));
            WebElement generateAlertTwo = driver.findElement(By.id("html_alert"));

            generateAlertOne.click();

            generateAlertTwo.click();
            WebElement closeHtmlAlertButton = driver.findElement(By.cssSelector(".ui-button"));
            closeHtmlAlertButton.click();
        }

Now this time the test will fail, but you will see the following error:

org.openqa.selenium.NoSuchElementException: Unable to locate element: .ui-button

It has failed because we can’t find the button that is used to close the HTML popup; the implication here is that clicking on the second generate alert button did not work. Now we know that this is not the case, this test is failing because we have removed the code that switches to the alert and accepts it. Can we make this clearer by writing a screenshot of what the test is seeing to file?

 @Test
        public void triggerBothPopups() throws Exception {
            driver.get(alertFileLocation);
            WebElement generateAlertOne = driver.findElement(By.id("js_alert"));
            WebElement generateAlertTwo = driver.findElement(By.id("html_alert"));

            generateAlertOne.click();

            generateAlertTwo.click();

            File screenshot = new File("screenshot.png");
            FileOutputStream screenshotStream = new FileOutputStream(screenshot);
            screenshotStream.write(((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES));
            screenshotStream.close();
            System.out.println("Screenshot saved at: " + screenshot.getAbsolutePath());

            WebElement closeHtmlAlertButton = driver.findElement(By.cssSelector(".ui-button"));
            closeHtmlAlertButton.click();
        }

Let’s run the test again; this time a screenshot will be generated and the file location will be shown in the console log. This should show us that JavaScript alert that is causing all of the problems.

If you now open up the screenshot and look at it, it’s probably not going to show you what you expected. The screenshot shows the rendered website with no JavaScript or HTML alerts. What’s going on?

JavaScript popups are not part of the website that is being rendered, they are instead rendered by the browser. As a result they don’t show up in screenshots taken by selenium. To all intents and purposes, it looks like we have found a bug with the website implementation. It looks like clicking on the second button does not trigger an HTML alert to be shown. However, if you go back and test manually you will see that it works.

We know what the problem is, but imagine how confusing this would be to somebody who didn’t understand that we had a mixture of different types of popups. You would probably raise a bug stating that the second button didn’t work and pass it back to a dev who would not be able to reproduce the problem (because the only problem that exists is a problem with the test code).

Working with other types of JavaScript popup

So far we have looked at only one type of popup, the alert. There are two other types of JavaScript popups that you may come across, the prompt popup and the confirmation popup. Let’s create the last bit of HTML we are going to automate, save the following as ‘popup.html’:

    <!doctype html>
    <html lang="en">
    <head>
        <title>Prompts in Selenium</title>
    </head>
    <body style="background-color: #6cb5ff">
    <div id="buttons">
        <button id="js_confirm" onclick="confirm('This is a JavaScript confirmation box, you can select OK or Cancel.');">Click me for a basic JavaScript confirmation box</button>
        <button id="js_prompt" onclick="prompt('This is a JavaScript Prompt, it wants to get some information.');">Click me for a basic JavaScript prompt</button>
    </div>
    </body>
    </html>

As before, we need to define the location where you saved the above HTML. Just replace in the below code with the path to the file you saved above.

private String popupFileLocation = “file:///popup.html”;

First of all, we will look at how we can interact with a confirmation popup. Confirmation popups will ask you a question that you can either agree to, or cancel out of. They will always have two options, ‘OK’ or ‘Cancel’. Popups like this are usually used to block code execution until you agree to something.

Let us assume that we are going to agree with the confirmation popup first of all.

            @Test
            public void triggerJavaScriptConfirmation() throws Exception {
                driver.get(popupFileLocation);

                WebElement generateConfirmationPopup = driver.findElement(By.id("js_confirm"));
                generateConfirmationPopup.click();

                driver.switchTo().alert().accept();
            }

The code is very simple, in fact it’s exactly the same as the code we used to automate the alert popup. If we don’t want to agree with the confirmation popup the code is just as simple:

            @Test
            public void triggerJavaScriptConfirmation() throws Exception {
                driver.get(popupFileLocation);

                WebElement generateConfirmationPopup = driver.findElement(By.id("js_confirm"));
                generateConfirmationPopup.click();

                driver.switchTo().alert().dismiss();
            }

The last type of popup we are going to look at is the JavaScript prompt. These are blocking popups that are used to get some information from you. When you use these types of popup you are probably going to be asking the user a question that they need to respond to, so we will have a look at how we can check that the right question is being asked as well as entering the required information. Here is our code:

            @Test
            public void triggerJavaScriptPrompt() throws Exception {
                driver.get(popupFileLocation);

                WebElement generatePromptPopup = driver.findElement(By.id("js_prompt"));
                generatePromptPopup.click();

                Alert prompt = driver.switchTo().alert();

                assert(prompt.getText().equals("This is a JavaScript Prompt, it wants to get some information."));

                prompt.dismiss();
            }

This time, after triggering our JavaScript prompt, we have decided to define an Alert object. We are going to be interacting with the alert more than once so it makes sense to do so for code clarity and cleanliness. We have then used the getText() command to get the text that is being displayed to the user and made an assertion to check that it matches our expected text. We have then decided that we don’t want to provide any further information and dismissed the alert.

What about if we decided that we did want to send over some information? In that case we would have written the following code:

            @Test
            public void triggerJavaScriptPrompt() throws Exception {
                driver.get(popupFileLocation);

                WebElement generatePromptPopup = driver.findElement(By.id("js_prompt"));
                generatePromptPopup.click();

                Alert prompt = driver.switchTo().alert();

                assert(prompt.getText().equals("This is a JavaScript Prompt, it wants to get some information."));

                prompt.sendKeys("Some information");
                prompt.accept();
            }

As you can see this time we have sent some information over using the sendKeys() command and then accepted the prompt. We could of course have still decided to dismiss the prompt after entering some information, but that’s a scenario we haven’t written. You could always try that one yourself.

It is worth mentioning once more that different driver implementations can act in many different ways, and different driver implementations can support different parts of the WebDriver API. If you are having problems it’s always worth trying a different type of driver to see if your code can work.

This blog is translated from English to German by Google.

Jun 22 2022

A Comparison of Automated Testing Tools

This automated testing tools comparison of popular toolsets will help you identify the right automation tool for your project. This is a blog post provided by Rai Kou on EuroSTAR Huddle, our online community for free software testing resources.

A defining factor for successfully applying test automation in software projects is choosing and using the right set of test automation tools. This is a daunting task, especially for those new to software test automation because there are so many tools in the market to choose from, each having different strengths and weaknesses. There is no tool that can fit all automated testing needs which makes finding the right tool difficult. Learn how to identify the right automation tool for your project with this qualitative comparison of popular automated testing toolsets in the market.

Overview of Test Automation Tools

Selenium

Selenium is the most popular automation framework that consists of many tools and plugins for Web application testing. Selenium is known for its powerful capability to support performance testing of Web applications. Selenium is the most popular choice in the open-source test automation space, partly due to its large and active development and user community.

HP Unified Functional Testing (UFT)

Formerly QuickTest Professional (QTP), this is probably the most popular commercial tool for functional test automation. HP UFT offers a comprehensive set of features that can cover most functional automated testing needs on the desktop, mobile and Web platforms.

TestComplete

TestComplete is also a commercial integrated platform for desktop, mobile and Web application testing. Like UFT, TestComplete offers a number of key test automation features such as keyword-driven and data-driven testing, cross-browser testing, API testing and CI integrations. This tool supports a number of languages including JavaScript, Python, VBScript, JScript, DelphiScript, C++Script, and C#Script for writing test scripts.

Katalon Studio

This is an automated testing platform that offers a comprehensive set of features to implement full automated testing solutions for mobile and Web applications. Built on top of the open-source Selenium and Appium frameworks, Katalon Studio allows teams to get started with test automation quickly by reducing the effort and expertise required for learning and integrating these frameworks for automated testing needs.

Test Automation Tools Comparison

The table below provides a comparison of the tools based on the key features of software automation.

Strengths and Weaknesses

Below is a summary of key strengths and limitations of the tools, based on the comparison above.

There is no one-size-fits-all tool for automated testing. It is highly recommended that testers evaluate various tools in order to select what would best meet their automated testing needs. Programming languages and technologies used to develop software continue to evolve, as do the automated testing tools, making cost a significant factor in tool selection.

Commercial vendors often charge for tool upgrades, which can be substantial if your software uses emerging and frequently changing technologies. Open source and non-commercial tools, on the other hand, do not incur additional charges but require effort and expertise for integrating new upgrades. It is difficult to find the support and expertise needed for integrating various tools and frameworks into open-source solutions.

Emerging tools that integrate with open-source frameworks offer a viable alternative to both commercial and open-source automated testing solutions.

This blog is translated from English to German by Google.

Jun 21 2022

Test Automation Framework Architecture Types

This article explains what a test automation framework is and gives examples to consider for your own development projects. This blog provided by Alexandar Pushkarev on EuroSTARHuddle.com, our online community for free software testing resources.

What is a framework?

According to Wikipedia, a framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software [1]. It isn’t the easiest definition to digest, and one can usually struggle to actually tell the difference between a framework and a library. The key difference between framework and library, however, is who calls what. Long story short, when you use library, you call library’s code. In comparison, when you use a framework, it calls your code.

Test automation frameworks are by no means different. In general, a test automation framework is something that allows you to implement application-specific test automation solutions by writing and injecting some additional code. Surprisingly, in the test automation community, by framework, people often mean any test automation solution that happened to have any decent structure and design. Wikipedia also supports this opinion [2].

The most common “architecture type” of a test automation solution I’ve seen was something that could be described as a “big ball of mud“. And, in some cases, it performs just great- such things don’t take ages to implement, and it’s quite easy to support for some short periods of time, if you have a limited amount of tests.

The really challenging question is why and when you need a real test automation framework, and when you may go with the plain “big ball of mud” test solutions.

Start with the question, “why?”

All in all, test frameworks are designed to address following issues:

1. Test complexity

The simpler the test is on the top level, the easier it is to create, understand, communicate and maintain.

2. Test maintenance cost

Test automation isn’t a thing that can be taken for granted; it has a price. One of the most painful prices for test automation is a maintenance cost. Well-designed framework should simplify maintenance.

3. Test execution time

Time is money. Time to get feedback from automated tests is also crucial – one wouldn’t like to wait for several hours, just to check that their commit wasn’t wrong.

4. Reporting

Testing is about not finding bugs or accepting stories. Well, not exactly. What testing’s really about is providing information. A test solution that has simple, maintainable tests – easy to maintain and enhance – may be just thrown away if it produces bad reports that are difficult to understand by non-technical stakeholders.

All things considered, if you don’t plan to have hundreds of complex tests scenarios, your tests are fast, and you’re happy with built-in Xunit framework – you may not need a test automation framework at all. The rule of thumb: the lower test level you’re interested in, the less complex your test automation solution should be. In most cases, you don’t need a framework for unit or integration tests, however you may want one for acceptance tests.

Regardless of what test level you’re interested in, there are some typical framework architectures that can be utilized. Most interestingly, framework architecture isn’t affected by test automation approach applied (keyword-driven, BDD, plain code or whatever), because those approaches affects only some layers (most prominently test layers) and don’t touch others. Let’s then take a look at the most known test framework architectures.

Layered architecture

While test automation frameworks are designed to address issues outlined above, it usually isn’t an overly complex software system. The most commonly known architecture pattern, known as Layered Architecture, is often used as a base for test automation framework architecture.

Components within the layered architecture are organized into horizontal layers, and each layer of the architecture has a specific role and responsibility in the application. Components within a specific layer are supposed to deal only with logic that corresponds to that layers [3].

Three-layered automation framework

The most known and widely used architecture for software test automation solutions is a three-layered architecture; in which the solution is divided into three logical horizontal layers – usually test layer, business layer, and core layer.

In such architecture, a test layer typically contains test scenarios itself, either in programming language or in any other form (like BDD feature files).

Business layer provides system under test (SuT) specific actions. For example, if we’re talking about online shopping, such actions may be ‘log in’, ‘add to cart’, etc.

Core layer is where real framework (who calls your code) really lives, and it deals with test orchestration, reporting and usually also provides low-level API to communicate with tested applications, like web-service facades, Selenium Web Driver wrappers, etc.

In a BDD inspired framework, a test layer will typically contain feature files, a business layer will contain steps definitions, while a core layer contains BDD- framework configuration and core component. For a data-driven framework, a test layer will contain data files, and a business layer will contain mid-level application specific abstractions.

Four-five layered automation framework

In case you may need something more complex, there are several options to enhance framework architecture. One of the options you may choose, is to extract validation code into separate level (or module, to be precise), which will be used by a business layer, while a core layer may provide interface or orchestration for validation.

In case you’re building hybrid framework, you may need a separate layer for data, so your test layer will have data and non-data tests. All this will add complexity to a core layer, so it may also be logical to separate it into several sub-levels at some point.

Plug-able test automation framework

In case your application is even more complex, you may want different validation for different environments, or different ways to communicate with applications for same tests (for example for testing desktop and mobile versions of the webpage). While it is possible to address this by creating sub-modules in core or validation layers, there’s also a neat way to do this completely opaque to the rest of the system. The idea is to use dependency injection and provide plug-able modules for validation and test-application interfacing.

The idea is essentially the same as in previous framework architectures, with only one difference – validation and facades implements the provided interface, which is used by a business layer, and concrete implementation is typically injected without the other layers’ knowledge about what was really injected.

Considerations

While it is often tempting to pick up the most complex architecture (just in case) or the simplest thing (faster to implement), it is often wise to complete some initial investigation of what you need, based on product vision or expected length of life.

Provided architectures are by no means a standard, they are just examples, and you may implement a plug-able three-layered thing, or even identify 7 different hierarchical layers. You may want some event-driven thing for testing of asynchronous workflow.

There are several typical highlights:

1) Try to make tests as simple, short, and atomic as possible. Ideally, tests should tell what’s being done, not how it’s done, and test only one specific things. Typically, the cost of complex test support outweighs benefits of having such tests.

2) Business layer should provide action implementation (how something is done), using interfaces provided by the core layer.

3) Validation layer should provide action implementation using interfaces provided by either core or business layers.

4) Core layer is the framework itself, and may have complex architecture on its own. Its responsibility is to provide interfaces for upper layer, and provide orchestration for test run and reporting. It also often provides low-level implementation for interfaces exposed to upper layers.

There’s no one-size-fits-all architecture, so you may suggest many other ways to separate test logic. The provided examples are just a starting point. What’s important is that you should be able outline the architecture of the solution you are working on, and guess if it fits to the project or application. My personal advice would be – stick to the simplest architecture that fits your immediate needs, but try to leave other options open in case you need them.

[1] https://en.wikipedia.org/wiki/Software_framework

[2] https://en.wikipedia.org/wiki/Test_automation#Framework_approach_in_automation

[3] Mark Richards, Software Architecture Patterns. O’Reilly Media, 2015

**This is an English blog translated by Google