Geek Culture
Published in

Geek Culture

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, I’ll describe the challenges we faced and the solutions we utilize within the project, we’ll also talk about interesting cases, bugs, and how we fix them.

The article is written by Vasyl Tarnapolskyi

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 companyManagementServicebefore(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 hope you enjoyed our new article. Stay tuned for what’s new!




A new tech publication by Start it up (

Recommended from Medium

How to build a SEO-friendly React blog with an API-based CMS

Finding the Angular Material Color Palette in Node Modules

In Depth Of React JS

The Git Way for a Node.js App to Get a Solidity Contract Balance

How to send DocuSign PDF into the mail.

Call a function periodically in Javascript (with memory leak analysis)

Let’s Learn: Higher Order Components and WebSockets

Testing your JavaScript in a browser with Jest, Puppeteer, Express, and Webpack

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Engineering Your Breakthrough

More from Medium

Let’s talk about testing

What Are the Challenges When Starting to Implement Tests

No more boilerplate code for properties files

Filter JUnit 5 tests on Gradle with command-line arguments