E2E tests are often neglected by frontend developers. Key reason - high complexity and a time-consuming writing process (and both are not cost-efficient). Yet, they tend to forget their biggest value - E2E tests replicate the actual user behavior.
End-to-end tests aim to cover as much of your application's functionality as possible, simulating a real user's actions. Therefore, such a test should include all the stages of an application. However, it can be different when it comes to E2E tests in React Native apps. Unfortunately, developers often overlook this topic because it seems overly complicated and simply not cost-effective.
Most of us, during daily work, focus on writing unit and integration tests, which in fact, have a significant impact on the proper development of any software. Yet, it is precisely E2E tests that provide incredible business value and give us the greatest certainty when it comes to the reliability of a given feature.
Why do E2E tests essentially have the greatest value? Before answering that question, let's take a moment to analyze the use cases of the other two types of tests: unit and integration.
Generally speaking, unit tests are tests of the smallest units (functions, hooks, components) where those individual units or components of a software application are tested in isolation from the rest of the application to ensure they function as intended.
They are designed to check their correctness (e.g., if the function returns the proper value or if the component renders the right output). Writing such tests is a great extension of every programmer's work because it forces us to follow proper programming practices. We can't write dirty code, because then we'll have huge problems writing unit tests for it.
That's why we must move functions or small functionalities outside of the components themselves. As a result, our code becomes clean and maintainable.
Of course, the main value of such tests remains to be the one to ensure that a given function or hook works as it should in all use cases.
Exactly, the certainty of operation is the most important issue here. While programming, we should feel that we are doing a solid job and that all the tiniest components work as they should.
Even though these tests give a lot of value and attention to detail, they are not as "appreciated" from a business point of view (except for nice figures on the code coverage report 😉).
Why? Because from a business point of view, the greatest value is given by tests that check the actual user’s behavior. Going function by function and checking if it returns the correct value doesn't sound like something that users do while using the application, right? So we need to go higher and think about how we can combine these units into a larger functionality.
That's where integration tests can help. As you probably already know, integration tests belong to a software testing method where application components are combined and tested as a group. However, sometimes the boundary between unit tests and integration tests is very arbitrary. But in my understanding, if we test any connection between two units, we are dealing with integration tests. Here’s where we're getting closer to the actual user behavior.
Now, let's move on to the crux of the matter, that is, E2E tests. In theory, they are quite similar to the integration ones. Their main task is to check the integration between the different parts of the application. However, they do this in a completely different way that is performed from the user’s perspective (on a simulator or on a real device).
In E2E tests, we don't think about React Native components, functions, hooks and other typical programming parts of the application. But we think about what does the user actually see when he enters each given view? Those could be buttons, inputs and other interactive elements.
So, where's the catch? Why don't we focus exclusively on these E2E tests if they give such value? Because writing comprehensive E2E tests is time-consuming, and they are much slower compared to other types of tests. Although, this doesn’t mean that we should completely forget about them, thanks to their ability to cover the most critical elements from a business point of view - the user's perspective. The key here is to find the right balance between implementation time and business value.
All the things I mentioned earlier can generally be applied to the entire frontend. However, we’ll focus on React Native in explanations and examples.
There are several popular E2E testing libraries among the React Native community, and two of the most commonly chosen are Detox and Appium.
The Detox library is characterized by its simplicity of implementation, especially for React Native developers. It allows writing JavaScript tests for both iOS and Android applications. Additionally, it supports modern JS syntax, using which we can select elements and trigger actions. To initialize this library in our project, we can use the CLI, which can be installed using the command:
Then, following the instructions in the comprehensive documentation, you can proceed to writing your first E2E tests. There are no major difficulties or anything that would pose a challenge for a React Native developer.
And what about Appium? In contrast to Detox, it’s not a technology built specifically for React Native. In fact, it was created even before the React library. It’s based on Selenium WebDriver and boasts a large community of users.
However, numerous differences in the API make it have a significantly higher entry threshold for those unfamiliar with such tools. Additionally, it is often difficult to find information online or to use certain React Native properties. It means that working with this technology, despite using one of the most popular testing frameworks, can be a real hassle for those accustomed to the React Native API. On the other hand, it can be a very pleasant extension for those familiar with the Selenium environment.
Alright, now that we've covered the basics, let's take a look at one more important topic. Sometimes, you may come across the question of who should be responsible for writing E2E tests.
Because, on the one hand, there are technologies that allow developers to implement the same approaches as when writing unit and integration tests in a user-friendly way.
On the other hand, E2E tests can be understood as an extension of the work of QA engineers and a handy set of tools for automating processes. The key here is selecting the appropriate technologies depending on the issue you want to resolve.
If you are a QA engineer and are at the beginning of your journey with test automation, diving into the Selenium platform and working towards Appium is definitely an idea worth trying. This way, without the need to adapt to new approaches and technologies, you will be able to learn something that may come in handy in other situations, e.g. automating web application tests (regardless of the technology).
And, if you are a developer looking to expand your skills, Detox is definitely a great choice due to its relatively low entry threshold and the ability to utilize something you’re familiar with.
I believe that knowledge of a specific technology should never be a factor in forcing a particular person to take responsibility for a corresponding part of a project. When working on a project at Apptension, we always work as a team.
Therefore, first and foremost, it is necessary to consider an optimal plan for dividing responsibilities in a way that would allow everyone to use their skills without neglecting their main duties. But I need to warn you that it’s hard to achieve with E2E tests as they are often perceived as a "borderline competence" part of the project.
To maintain the greatest flexibility when making project decisions, it's great to give the employees a choice. The perfect case scenario is having both developers and QA engineers that are experienced in this area. Then, we are able to choose the appropriate approach to the need.
That’s why the willingness of your teams to develop and learn new technologies is truly important. So, I strongly encourage you to learn the basics of any of these technologies. There is no doubt that sooner or later there will be an opportunity to put this knowledge into practice.
Looking for more testing tips? Read our recent article about Manual security testing in a browser.
Explore our collection of insightful blog posts.
.png)
.png)
.png)
