What is frontend testing and how do I've done it.

I’m kind of new on testing and I really don’t know all of the differences between the types of it or all the differences between the softwares that are available (Jest, Cypress, Mocha, Selenium, …), but a few things that I can share are the way that my friends and I have tested them until now and what I’ve learned about them.

I took some lessons with Kent C Dodds (a Paypal developer) before writing this text and on his workshop he said that testing is a way to be more confident on deploying your application to production. I share the same thought. Once you have tests, it is easy to check if everything is running well in a short time, consistently and automatically. It’s a fail-safe in your product.

The way that Kent sees the testing pyramid, like a The Testing Trophy

Until now, I’ve done a few tests E2E and I can say that I have done TDD (Test driven development) just on a backend application (I’ve never done it on frontend, despite the fact that I know how to do it).

In most of the projects that I have developed (looking on frontend applications), I have always done it when it was already on production, and I got to say: if we had done it before, our applications could be way more secure to develop and way more documented than they are. And yes, I think that creating tests is a good way to document the code and the business logic.
Before we go on to the applications that I’ve tested, it’s good to understand the difference between the kinds of testing:

Before we continue our tour between the applications that I have tested, it’s good to understand the difference between the kinds of testing.

• Static: This is actually kind of new to me. Until the Kent’s workshop, I hadn’t thought on its testing purpose, but it’s nice to mention it here because it is a big part of the “testing trophy”. Basically, this is the Lint that you have in your code, like ESLint, for example. It checks your code and if there’s anything wrong, the linter will show you what it is.
• Unity test: It’s the simplest, cheapest and fastest test that you can have. The aim here is on the SMALL PROBLEMS. Most of the time, you test a component or a function. It’s a good thing to have lots and lots of this tests around your project. Most of this codes you’ll write just once and it will be responsible for checking fast every time the unit component.
• Integration test: Here, as the name suggests, you integrate two or more components or functions to have a result. You can use your server mock and check fluxes with your test.
• E2E test: Different from the unity test, this one is expansive, slow to check and to develop. Also, it is used to test BIG PROBLEMS. It’s a kind of test that tries to check a routine, a test that needs to go from A to B and, on this one, you really should use your backend to check the results. In some examples that I’ve seen, the developers just test the Happy path, not checking for errors.

Basically, what you try to achieve with testing is the fail-safe to develop anything to production and check if the logic that you are coding is good enough for you and your team.

Moving on to business logic, most of the frontend code that I’ve done has been on integration tests and the biggest part of them were using Crypress (a powerful tool to do tests end to end). With that experience, I would like to share a few obstacles that I found:

• Mocking backend requests and results: Cypress have natively some Stubs tools, we can use the router to get the request and throw back some response that we expect (the ones that we have documented with our backend), but, if the backend change the request or the response, we will not be able to test and check if this is ok;
• Browsers support: Cypress have natively some Stubs tools. We can use the router in order to get the request and throw back some response that we expect (the ones that we have documented with our backend) but, if the backend change the request or the response, we won’t be able to test and check if it’s ok;
• Cypress Bugs: this is a bit confusing, but we have found some bugs during our tests that were checked as “pass” once we re-rolled it to check again. In a few times, we’ve noticed that the bug was on frontend, but most of the times was a bug on the Cypress itself;
• The rewrite again and again: most of the times that we have a change on the business logic, we had to adapt our tests. It’s fine because THIS IS WHAT TESTS ARE MADE FOR, right? But since this is the heaviest part of our tests, we have to go back many and many times to check all the points from A to B.

Knowing that, I can also share my experience with a few projects.

Atena

Atena is a dashboard where the client can see the deliveries and their status at the moment. We use a self-made style library that contains a few unity tests, but most of our tests are made by integration.

On Integration, we test from the auth to a possible delivery cancellation. We check all of it with the backend mock.

The application is not that complicated. The checkpoints are simple and there’s really just a few things to check. Our tests run in about 7 minutes. We check in every commit (with Bitbucket pipelines) and we do it again when it merges with the master branch.

Hermes

Hermes is a client journey to get a delivery service (it’s like the end of the process of buying anything on an e-commerce website).

The client checks the basic information of the delivery pack, selects the carrier that he wants to use, fills the delivery address and a few more information to get the instructions to continue.

Due to the simplicity of the client flux, the integration goes through every possible error and double check every possible component mocking the backend data (that’s the reason why it is by an integration, not an E2E).
Those tests run in about 12 minutes. We check in every commit (with Bitbucket pipelines) and we check again when it merges with the master branch.

After all the considerations above, the next step I’ll take is going to be to compile what I’m gathering with friends and companies that have tests on frontend and see how they run and develop those tests.

Stay tuned!

If you want to see more about testing, check out these materials:

But really, what is a JavaScript test? — Kent C. Dodds
Learn to Test React Application — FrontendMasters