Test Coverage: from zero to stability

Starting point

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:

describe(‘Validate CompanyManagementService’, () => { let user let companyManagementService before(async () => { user = await setUp() container.snapshot() container.rebind(types.UserService).toConstantValue(userServiceMock) companyManagementService = container.get(types.CompanyManagementService) })

E2E tests against the monotonous work

We completed business logic coverage but realized that the problem with manual testing was still there. We started to work with E2E tests to fix it, which eliminates the monotonous part of testers’ work. After long discussions, we agreed on finding a JavaScript framework, which, actually, can be supported by every developer from the team, in case we need it. That is how we decided to choose Cypress.

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.

With the E2E tests, we fully covered the main flow, which our clients mostly use, and which we have to test a thousand times per month. It was a cool decision to implement them, as it helped us to find and fix unexposed bugs. Speaking about disadvantages — as usual, there is not enough time to write new tests and it is really hard to find QA engineers with JavaScript and Cypress knowledge. I would like to notice, that this point is quite critical, and could be the main reason why we may stop using Cypress, despite all its advantages.

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!