Test Coverage: from zero to stability
Project’s overview. Our client is a digital B2B marketplace that automates the procurement of metal parts for industrial medium-sized companies and metal construction. The main idea of the business is to create an online platform, where people can order metal parts faster and cheaper than in any other place.
Our part in the project was to improve the customer portal and enhance communication between the clients and the producers. The business evolved and requirements for the platform grew with it too. At first, there was one QA engineer able to fulfill all the project’s needs. For now, there are three testers, who frequently feel a lack of time to accomplish the tasks. Accordingly, we realized that we need to automate the QA Engineer’s work, as much as possible, covering the code with tests.
In this article, we’ll describe the challenges we faced and the solutions we utilized within the project. We’ll also talk about interesting cases, bugs, and how we fixed them.
Mocha and Chai as a business logic treatment
The developers’ team was worried about the proper work of business logic for different cases on the server-side. That’s why we started our test coverage with Mocha and Chai. We also implemented Dependency injection, which gave us the possibility to easily substitute services and quickly write tests.
For example, we have CompanyManagementService which has userService as a dependency. Then mocking dependency with InversifyJS will look like this:
E2E tests against the monotonous work
Pros and Cons of Cypress
The work with this framework began with a one-day workshop. Everyone had an opportunity to try Cypress in action, write tests.
We faced a problem of high preoccupancy within the project. That caused a small delay in work with Cypress. Nevertheless, the solution was obvious, and once we hired a new software engineer, instead of integrating him into resolving business problems, we set him to work with Cypress integration.
Impressive Jest power
One more vulnerable part of our project was — Vuex.
Based on the fact that we have ‘Actions’, that could reach over 100 lines, we couldn’t grant an unexpected result there.
So, we decided that it would be a perfect kickoff for our UI test coverage. At this time, we chose to use Jest. Mainly because it can run tests in parallel and also because it has everything for out-of-the-box testing. Jest is really fast, for now, we have a bit more than 200 tests and they run for 6 seconds, which, actually, impressive:
Let’s talk about some interesting cases. While we were covering Vuex, we found some places in a code that worked in the wrong way for a long time.
For example, we’d changed the name of the property from ‘getMinimumOrderValue’ to ‘getMinimumOrderValues’ in State, but it wasn’t updated in other places. That caused unexpected bugs, hard to be caught with the E2E tests or manual testing. As we found similar problems during testing, the time spent on test writing fully covered itself during the time of writing.
As follows, even though our business is growing very fast every day, we introduce new functionality, we still keep our system safe, stable and resolve most of the problems long before the end-users might meet them.
Thanks for reading. We’re already working on the next article. Check up more of our blogs meanwhile.
Stay tuned for what’s new!
Let’s engineer something
79015, Smal-Stotskoho St. 1 Ukraine
50-062, Plac Solny 15 Poland
Nieuwe keizersgracht 1 A Netherlands