6 Tips for Efficient Front-end Testing

Everyone knows it’s necessary, but everyone hates it: automated front-end testing. I get it - writing tests can be tedious and unfulfilling. But at the same time, it helps you discover bugs and dramatically reduces manual work. I want to give front-end testing some love and share some tips and tricks about it. After all, things are much more fun when you’re good at them!

1. Choose a Well-established Testing Framework or Library

The JavaScript ecosystem can feel overwhelming: There are so many options to choose from, and trends change fast. But some tools stick around for multiple years and manage to keep a high satisfaction rating in the yearly State of JS survey. Those are the tools you want to use!

Why? They are battle-tested. The community has already resolved the most apparent limitations and bugs, making your life a lot easier. Also, most modern testing frameworks are excellent - there’s not much to gain from trying out a new one. Maybe you find one that is 1% better, but is that worth the struggle? I think not. Do you disagree? Let me know on Twitter!

2. Test State Almost 100%; Test Everything Else Less

This rule of thumb is almost self-explanatory: Front-end development is all about state management, and ugly bugs are mostly related to state. Therefore, we should focus our testing effort on state as well! If you want to learn more, look at Adam Craven’s description of a closely related principle.

3. Restructure Your Code to Improve Testability

Sometimes, a unit seems almost impossible to test: There are lots of external dependencies to be mocked, and the code is structured in a way that makes it hard to test parts in isolation. This usually indicates that the unit needs to be reworked. Please clean it up as soon as possible!

If you work in a high-stress environment and feel pressured to deliver features fast, this tip might seem unrealistic and inefficient. But keep in mind that the Pareto principle applies to bugs: 20% of code often contains about 80% of all bugs. A rework of terrible units might drastically reduce the time you need to spend on bug fixes in the future!

4. Think About Testing From the Very Beginning

Maybe you know this situation: You just finished a complicated feature. It’s finally done, and it only took you two days! You are proud of yourself. You have a quick cup of coffee before you start writing tests. If all goes right, you will be able to request a code review tonight! Woohoo! But a full day later, you are still not done. Why does this take so long? Why is it so complicated?

I’ve been in this situation more than once. Back then, I thought this was the way to go: prototype, clean up, then test. I was so wrong! As explained in tip 3, some code is structured in a way that’s exceptionally hard to test. If you don’t think about this fact while developing a feature, you might write code like that! What’s more, when writing tests, I usually discover at least one bug in my code. Then, I have to go back, fix it, and test everything manually again (because tests aren’t fully done yet). This is inefficient! In my experience, it’s more productive to start writing tests (or at least think about them) while still working on the feature, and I strongly recommend this approach.

5. Specify a Goal for Your Tests

Many teams aim for a certain amount of test coverage, e.g., a minimum of 80% line coverage. However, a high coverage doesn’t necessarily imply your program is well tested! Also, what does »well tested« actually mean? What do you want to achieve by writing tests? Sometimes, you may want to reduce the risk of critical failures. In other situations, you may concentrate on a specific edge case. Maybe, you want to avoid regression bugs. Define your goal before you set the rules!

6. Carefully Evaluate the Pros and Cons of End-to-end Testing

Some people love end-to-end testing. There’s no mocking or stubbing, and tests resemble actual user behavior closely. If your test passes, you can be confident the tested feature works - in all tested browsers! What’s not to love about that?

Well, end-to-end tests are often flaky. When your test suit gets large enough, you will experience false positives regularly. That’s not too much of a problem but still requires additional maintenance work that you must budget. It doesn’t help that end-to-end tests are slower than most other tests. Imagine waiting half an hour for your CI/CD test suit to finish, only for the last test to flake out. What a great way to end your workday!

To summarize: Use end-to-end tests where they help reduce manual work but avoid them otherwise. Never use them instead of unit tests!

I hope these tips help you level up your front-end testing skills so you can enjoy writing tests a bit more. Let’s spread some love!