Life Without Front-end Tests

Recently, I received a newsletter email from the founder of egghead.io. You can read the message on his blog. He explained, why they didn't have a single test in their front-end applications.

Many of the reasons and experience he described, resonated with me. Joel's transparency and openness encouraged me to share blogfoster's testing journey as well.

The hard and unpleasant truth is that we didn't have any test in our front-end applications since a month ago.

Why didn't we write tests?

Best practices & knowledge: We have started to use React at the end of 2015. Back then, testing approaches with React haven't been developed and adopted so much. Additionally, we haven't had any experience with testing approaches with React either. We knew the Selenium style which wasn't an option for us.

In the situation of building a product, we didn't invest enough time to put in place a solid baseline of tests.

Writing tests in the front-end is not so convenient compared to backend testing with node.js. In my opinion, this is still the most common reason for not having a well tested front-end application. It is confusing, there a many opinions, and too much options.

Integration vs Unit: We prefer integration over unit testing. From our experience, integration testing has a higher probability to detect failures.

Two years ago, we didn't know how to write maintainable and stable integration tests. That was an extra reason why we ended up with no tests.

We have settled with cypress.io and snapshot testing recently to increase the test coverage.

Starting a business: In 2015, we were in the middle of getting traction with our idea and company. The speed of the development was important to survive and prove a working business model.

We defined focus and priority with our small team. We invested our time with testing into the business logic of the APIs instead of the front-end applications.

Someone could argue about quality. True … but it doesn't mean you'll end up with bugs everywhere just because you don't have automated tests. Bugs were expected and accepted to some degree in this situation.

Conclusion

I'm not proud of it and I regret it to some extend. On the other side, the product and company is doing well, even though we went through this journey.

Packed with our current knowledge, it would have been much easier for us to write tests. But more importantly, writing the right tests that cover the expensive bugs.

The most important question is how to proceed with a product that is used by many people. You should definitely not continue the strategy with having no tests. At blogfoster, we started experimenting with Storybook and cypress.io. Learning them, and increasing our coverage step by step is our mission. Skills and knowledge don't come overnight. You need to invest time and effort for better quality and that's what we do.

We can't change the past but we can influence the future!

Written by myself. This article has been originally published on blogfoster’s engineering blog.