Tiny Tests, Large Results
From Author:
Yes, Big things do come in small packages. For example, isn’t a unit test’s speed, feedback, and reliability fantastic? Did you know we can also have fast, focused, and reliable feedback from our functional e2e tests? Atomic e2e tests are those that are targeted and focused. They’re tiny in size but large in their impact. This tutorial will teach you how to create atomic e2e tests with several code examples. First, we will use Cypress.io to authenticate by setting a cookie. Instead of using a UI. Second, we will use Cypress.io to set a JSON Web Token for authentication. Join me, and let’s write tiny tests for large results.
This talk has been presented at TestJS Summit 2022, check out the latest edition of this JavaScript Conference.
FAQ
Automated atomic tests are tests that focus on a single feature or component, typically involving very few UI interactions and touching a maximum of two screens. They are designed to be faster and more stable than traditional automated tests.
Automated atomic tests are beneficial because they reduce latency and the number of UI interactions, making them faster and more stable. This enhances test efficiency and reduces brittleness.
Automated atomic tests improve UI testing by minimizing the number of UI interactions and focusing on individual components or features. This approach leads to less brittle tests and faster execution times.
An example of an automated atomic test is checking a link's Ahrefs attribute without clicking the link. This makes the test faster and less brittle by avoiding unnecessary actions and validations.
In a web application with an HTML form, automated atomic tests can bypass the UI by making a web request that drops a cookie in the browser, allowing login without UI interaction. This method is demonstrated by logging in and being redirected to the dashboard on success.
The challenge with non-atomic tests is that they often involve repetitive and unnecessary actions, such as logging in through the UI multiple times. This can make the tests more brittle and less efficient.
JSON Web Tokens (JWT) authenticate users by submitting a request with login credentials and receiving a token. This token is used for authorization in subsequent requests, allowing access to protected parts of the application without UI interaction.
To perform an atomic login using JWT in Cypress, you authenticate a user with a username and password, store the returned token in local storage, and use this token for subsequent requests to access protected resources.
Avoiding repetitive actions in automated tests is important because it reduces test execution time and prevents brittleness. This leads to more efficient and stable tests.
More resources on automated atomic testing can be found in the ReadMe of the relevant repo, as well as on ultimateQA.com and associated social media channels.
Video Transcription
1. Introduction to Automated Atomic Tests
Automated atomic tests are a wonderful way to update your UI tests and make them less brittle and drastically faster. We're going to see a few examples of those automated atomic tests, and we're going to even implement those automated atomic tests on two web applications. An automated atomic test is a test that tests only a single feature or a component. They typically have very few UI interactions and typically touch a maximum of two screens, especially with front-end UI automation.
In today's tutorial, we're going to talk about automated atomic tests. Automated atomic tests are a wonderful way to update your UI tests and make them less brittle and drastically faster. We're going to see a few examples of those automated atomic tests, and we're going to even implement those automated atomic tests on two web applications.
One application will have an HTML web form and another will use a JSON web token for authentication. My name is Nikolay Advolatkin, Senior Solutions Architect at Sauce Labs and founder at ultimateQA.com. So, what are you waiting for? Let's go and check out how to implement automated atomic tests.
An automated atomic test is a test that tests only a single feature or a component. They typically have very few UI interactions and typically touch a maximum of two screens, especially with front-end UI automation. The reason why I say they typically touch a maximum of two screens is because these automated atomic tests will typically have a setup state where they need to set up the state of an application and then a post setup state where they need to perform a validation. Automated atomic tests have several good environments in that they are much faster and much more stable than your typical automated tests due to the fact that they decrease the amount of latency that we have to deal with and they decrease the amount of UI interactions that we have to perform.
2. Analyzing Automated Atomic Tests
This test might look atomic at first, but it's not. It requires logging in and validating the login, which can be done separately. Atomic tests can be simple, like validating link attributes. We'll now look at an HTML web form application and a positive test case called 'Redirects to Dashboard on Success'. The test visits the login page, interacts with the form, and performs assertions to validate the login.
Now I got a question for you. This test over here, if you look at it and analyze it, do you believe this test is atomic? At first glance, this test might actually look atomic, right? In that it's signing in, validating that we were able to sign in and then it adds an item to a cart and asserts that an item was added to a cart. It's close to being atomic, however it's not actually atomic. The reason why it's not is because it has to login and validate that we have successfully logged in. There is no reason why we can't test the UI login in a separate test and ensure that works and then afterwards, what this test really cares about, what it actually wants to test is this portion right here. And so we can save time and stability by performing these interactions without using the user interface.
Atomic tests can come in many forms. Some of them can be extremely simple. For example, when we used to write automated atomic tests that click links, we actually have a wasted action and a wasted validation in that we need to click a link and assert that the link goes to the right location. What we're actually interested in is the Ahrefs attribute of the link, which we could easily validate in this manner, making our test faster and less brittle.
Let's go ahead and take a look at our first web application, which is going to have an HTML web form, and we're going to be able to log in to this HTML web form. But instead of using the UI, which is not efficient and not atomic, we're going to be able to make a web request that's going to end dropping a cookie in our browser, and then we're going to be able to bypass the log in without interacting with the UI. If we come to this application, there are many tests that are here, but I'm going to focus on one at a time, just to give you a better understanding. The very easiest test to understand, which is the positive test case, is going to be this test case here called Redirects to Dashboard on Success.
This is the very positive test case where we visit the login page, and by the way, you can see our application on the right hand side, if you're not familiar with Cypress. It displays the test execution on the left, with the actual application on the right, and if you did want to explore the application in another browser, you definitely can. Here it is, and it performs all the same exact operations, but with Cypress, for example, it's very easy in that you can see what the test is doing and then see the actual application on the right hand side and even interact with it if you wanted. You can see that the very first step that this test does is it visits the forward slash login of our application that is on local host 7077, and after that, it performs the standard operations that you would expect in order to actually be able to log into the application, right? So it's going to get the username and type in Jane Lane. It's going to get the password field and type in password and then it's going to submit the form. Once the form is submitted, you can see we do a couple of assertions. First, that the dashboard page is there, right? So our URL includes dashboard forward slash dashboard. So that means that we were able to successfully log in. Second, we get the header and assert that it contains Jane Lane. So almost checking not only that we're logged in, but that contains the right user and we get the cookie that corresponds to our login and make sure that there is a cookie that exists. So take a look at the application tab here and in our cookies. Currently, there is nothing available here. I've cleared it. But if we rerun the test, and of course, as I mentioned, it does interact with the application actually logged in. You can see that now there's a Cypher session cookie that's dropped, hence why we are able to log in through the application. The challenge with this test is that, again, it's not atomic, right? In that it does interact with this login form, and then it logs in, and then it validates that we're logged in.
Available in other languages:
Check out more articles and videos
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Workshops on related topic
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
He will walk you through:- Component Testing- API Testing- Visual Regression Testing- A11Y testing
He will also talk you through how to get these all setup in your CI/CD pipeline so that you can get shorter and faster feedback loops.
Table of contents:
- Cypress Real World App Overview
- What is Flake?
- Causes of Flake
- Managing Network-related Flake (Activity)
- Managing Dom-relate Flake (Activity)
- Flake Detection and Mitigation Best Practices
- Q&A
Comments