Frontend Test Automation
Hi there!
It’s widely known on software development that when there is pressure to deliver, there is no time for documentation and testing. However, I was very lucky in the last months because our client wanted to invest time on test automation. And we did it! So let’s talk about our experience regarding FE Test Automation.
Those are the questions that I’m trying to answer in this article:
- Why we wrote tests?
- Which process did we follow in the team?
- What type of tests did we write?
- How to write tests?
And these are the conclusions, keep reading if you want to know about the details.
This is the Chapter 3 of the series “How we made our project more maintainable”.
Why we wrote tests?
Let me tell you why I think I was lucky, which are the benefits for the project and for the developer of adding test automation?
Confidence
I would prefer to catch a bug locally than get a call at 3am because something needs to be fixed. And of course, the client would have more confidence on the team if they don’t need to make those calls.
Saving Time
I often find myself saving time when I have implemented tests. Sometimes I need to invest more time during the implementation, but not always; writing test could help you to develop your feature quicker. However, those tests will save time on maintenance in the future.
Which process did we follow in the team?
Test automation should be a topic for the whole team:
- Product Owner: the PO should prioritise the tickets to implement tests. I didn’t work for us when the tests are part of the “Definition of Done” and they just need to be done. They are just a task to be done, like any other task, and they should be defined and prioritised independently.
- QA Team: the QA team should be the one defining what need to be tested. They know how the code should work from the final user perspective and they know which manual tests are the most time consuming. Therefore, the QA team defines all the tests to implement in our documentation.
- DEV Team: the DEV team should provide information about the Design System, because it’s important to know how is the code structure to properly structure the documentation and to help the QA team to define the scope of the tests. Of course, the DEV team should implement the tests when they are defined.
Which are the available types of tests?
On Frontend Development there are 4 types of tests that can be implemented:
- Static: there are not exactly tests, but they help a lot to catch bugs. Static typing (with TypeScript) and linting rules (with ESLint) are a must have in your project.
- Unit: Testing independent components in isolation.
- Integration: Testing several components together without any connection to the Backend.
- End to End: Testing several components together with connections to the Backend. So the Backend is tested as well.
What type of tests did we write?
To decide the type of tests we wanted to write we have analysed three factors:
- Confidence: the point of writing automatic tests is to avoid investing time on manual testing. But for that, we need to be confident enough on our tests.
- Speed: how fast the tests run is a key factor to define how we include the automatic tests in our workflow. If they are fast, we can run them more often.
- Cost: some tests are quick and easy to implement and to run, some others take a lot more time, which means more budget is needed for test automation.
Confidence
When we do a manual test, we test our code as a final user would do. In my opinion, this is the most important fact to keep in mind for this topic.
And as we love to work as a team, we wanted to be able to onboard the Product Owner and the QA Team on this journey. So, we need to talk about Design Systems. Because we followed the Atomic Design from Brad Frost system to structure our components.
Therefore, there is a relation between the type of testing and the component structure. Let’s make a table, I like tables:
This is relevant, because we want to test our application as a real user. So testing the components independently doesn’t guarantee that they are working well together. Which means that we want to test the pages, because the user is not using a component (“atom”, “molecule” or “organism”) isolated, not even a “template” without data. Therefore, Unit test didn’t provide enough confidence, so… out!
There are many jokes about how useless could be the unit tests on FE development, I just bring one to relax a bit.
So, when you click the button, the umbrella opens. Great! All the unit tests pass: the button is working and the umbrella is finally opened. Who cares if both components are working well together?
When we are writing integration tests, the backend is mocked; but for End to End (E2E) tests we are testing the full code. So, the E2E will be a better option because they provide more confidence.
Speed
There are two types of speed to measure: to implement and to run the tests.
In general, Unit Tests are quick to implement and to run, Integration Tests need more time and E2E tests could need a bit more time to implement, but a lot more to run. Let’s update the table!
Cost
The costs of implementing and running the tests are 100% related to the speed. If we need more time to implement the tests, it would be more expensive. And if we need to run the tests on our local environment or on the Continuous Integration, it would be more expensive if we need to wait more time for them to finish or we need more power on the servers.
Write tests. Not too many. Mostly integration
Finally we need to make a compromise between confidence, speed and costs. For most of our cases where we need to tests the FE (i.e. forms, layouts, tables, charts) we end up writing integration tests. And for some other cases (i.e. sign up, login, checkout), E2E tests would be a better option, because the full process (FE + BE) is tested.
How to write tests?
We want to have tests because they bring us confidence that our code is working. But to maintain all the tests could be very time consuming. So we need to pay attention how we write them, maybe we can reduce the time spent on maintaining the tests.
Once again we should keep in mind that we write code for the final user who is going to use it. When writing tests, we don’t care how the code is written we care about the final output that the user is going to use. In other words, we don’t want to test implementation details.
On one hand, implementation details are the parts of the code not relevant for the user: class names, html tags or any other attributes that we use to make the code works. On the other hand, the final output like titles, buttons, input fields or labels, are what the user see in the screen; and they are 100% connected to the business requirements.
Therefore, if we don’t tests implementation details, we only need to update the tests when the business requirements change. We don’t care if we introduce a new library, if we need to do a refactor or whatever happen in our code; as far as the output is the same.
A lot more can be discussed, but this post is already too long. So here you have a link with more information about the topic in the following link from Kent C. Dodds.
Conclusions
- Involve the whole team in the process.
- Write tests. Mostly integration and maybe some E2E.
- Do not test implementation details.
If you want to learn about testing. You should follow Kent C. Dodds, a nice start would be this article about test automation:
