Front-end Testing Principles
Writing front-end tests can be very difficult. You have so many things to consider, choices to make, and paths you can take. In this article, we’ll look at 5 principles to write better tests and give you full confidence to push new features into production.
Before starting, it is important to mention that this article is :
- Focused on front-end testing specifically (i.e. React applications and their interactions with components).
- Highly based on content written by Kent C. Dodds, who is a famous developer within the React community (https://kentcdodds.com/).
I) Introduction
In a previous article, we answered the question “Why do we write tests?” as well as defined a test strategy: the “Testing Trophy”.
Now it’s time to see a set of 5 principles that match perfectly with that philosophy.
II) Principles
1. Test your software in the same way that your users use it
We want to write maintainable tests that give you high confidence that your components are working for your users.
And for the Front-End we need to focus on only two targets for our tests:
- The end-user who interacts with your component in the browser.
- The developer who renders and uses your component in the code.
So long as your tests serve those two, then they have reasons to exist.
But far too often we introduce a third user, the test user. This user usually tests stuff that neither our consumers nor our business care about (Ex: testing implementation details).
But by testing in this way, you’re just getting confidence for a user who :
- Doesn’t pay the bills like the end user.
- Doesn’t affect the rest of the system like the developer user.
In addition, you now have to keep that third user in your head and make sure you account for changes that affect the testing user.
Resource: Kent C. Dodds — Avoid the test user
2. Avoid testing implementation details
The test user tends to test what is called “implementation details”.
And implementation details can lead to :
- False negatives: Can break when we refactor application code.
- False positives: May not fail when we break application code.
It’s why in most cases we want to avoid them, which will make our tests:
- Closer to how our users (end-user and developer) use our components. Which gives us confidence that our application is working as intended.
- More resilient. Refactors of your components won’t break our tests and therefore won’t slow our team and us down.
Your tests should be more focused on real use cases that your users can meet.
How to determine an implementation detail?
— If our test does something that the consumer of our code doesn’t, then it’s testing implementation details. (Exposing a private function by example).
— If an internal refactor (changes to implementation but not functionality) breaks your tests , then it’s testing implementation detailsExample of “implementation details” :
— Internal state of a component
— Internal methods of a component
— Lifecycle methods of a component
— Child components
It’s important to notice that there are still some cases that would require testing implementation details. In React, we can think for example about a custom hook with a lot of internal logic and which would be shared across your application.
But those should be rare and well-chosen.
3. Write fewer, longer tests
Many people read the list of requirements for a component and turn those into individual test cases. Maybe you’ve read about a so-called “only one assertion per test best practice.”
But that rule was originally created because testing frameworks did a poor job of giving you the contextual information you needed to determine what was causing your test failures.
Nowadays, thanks to our amazing tools, identifying which assertion resulted in the failure is trivial. And If you’d like to make things even more clear, you can add a code comment above the assertion to explain what is important about the assertion you’re making.
Don’t worry about having long tests. When you’re thinking about your two users and avoid the test user, then your tests will often involve multiple actions and assertions and that’s a good thing. Don’t arbitrarily separate your assertions into individual test blocks, there’s no good reason to do so.
How to determine your test?
Think of a test case workflow for a manual tester and try to make each of your test cases include all parts to that workflow.
Resource: Kent C. Dodds — Write fewer longer tests
3. Write your tests with ease of understanding and maintainability in mind
The AHA Programming Principle stands for “Avoid Hasty Abstraction.”. It says that you shouldn’t be dogmatic about when you start writing abstractions but instead write the abstraction when it feels right and don’t be afraid to duplicate code until you get there.
Finding a sweet spot in the middle of the spectrum of abstraction is key to developing maintainable code.
That principle can totally be applied to writing maintainable tests. As a reminder, you write a test to have the confidence that the code you are pushing in production today won’t break in case of a change later. But tests should also be a helper to you or any other developers who might come back to it in the future to easily understand what the purpose of the tested component (In terms of functionality and critical feature) is. In this way, you want to have your test easy to understand as well as highly maintainable.
Resource: Kent C. Dodds — AHA Testing
4. Write your tests in isolation
Having tests in isolation means that the side-effects of running one test shouldn’t influence other tests’ results. We should be able to execute them independently in any order, without changing the result obtained.
Having tests in isolation is an important principle of testing in general because it’s one of the most cause of flaky tests (Test which fails to produce the same result each time we run it) when it’s not well respected.
Since tests should be standalone and their execution order doesn’t matter, Jest can runs them in parallel, which considerably improves the total execution time.
Writing our tests in isolation will guide us to a better way to write your tests to improve their reliability, simplify the code, and increase confidence.
Resource: Kent C. Dodds — Test isolation
5. Be careful with mocks
Mocks are considered as stopgap mechanisms which allow us to test certain things that would be difficult or lazy to test otherwise (For example: Testing a credit card service, we don’t want to play with the production’s data and services and so the real money).
Please bear in mind that when we mock something, we’re making a trade-off. We’re usually trading confidence for practicality. Even if we have confidence that our code works with our fake version of service, we can’t have 100% confidence that our code will work in production with the real version.
There are definitely some places for mocks (In particular, when we’re talking about the different levels of testing), but we need to be conscious that we make a trade-off.
Resource: Kent C. Dodds — Test mocking
III) Conclusion
As I said, Front-end testing is challenging. To write relevant tests, you have to detach yourself from your own developer mindset and instead try to think as a real user would do, considering the UI as a whole. Since other developers will come after you to add their own pieces of code and tests, you also need to pay a lot of attention to maintainability and understandability.
Remember that the main purpose of writing tests is to increase your confidence in your application. You want to be sure that the functionality implemented works today as expected and won’t break in the future. Writing tests for the sake of writing tests (or matching arbitrary minimum code coverage) have no value and often results in a waste of time and money.
I hope these principles will help you on this journey.
Thank you for reading.
