How we built a tool to address testing challenges at Grab

Photo credit: welcomia / 123RF

This article was co-authored by Shivkumar Krishnan (engineering leader at Grab) and Vineet Nair Kallazhy (technical writer at Grab), and is part of Tech in Asia’s content partnership with Grab. Visit their engineering blog here.

At Grab, we look at launching new features or improving existing ones. This means that we need to develop fast without compromising quality—a difficult balance to strike.

To tackle this, we developed Mockers, a tool to expand the scope of local box testing. In local box testing, developers can test their microservices without depending on an integrated test environment. It is an approach to implement “shift left testing,” where testing is performed earlier in the product life cycle. This makes testing easier and fixing bugs less expensive.

The complexity we’re addressing

Grab employs a microservices architecture, with over 250 microservices working together. Think of our application as clockwork with coordinating gears. Each gear may evolve and change over time, but the overall system continues to work.

Each microservice runs on its own and communicates with others through lightweight protocols like HTTP and gRPC, and each has its own development life cycle. This architecture allows Grab to quickly scale its applications.

However, the complexity of a microservices architecture makes testing much harder. Here are some common challenges:

• Each team is responsible only for its microservices, so there’s little centralized management.
• Teams use different programming languages, data stores, etc. for each microservice. This makes it hard to construct and maintain a good testing environment that covers everything.
• Some microservices have been around since the start, some were created last week, some were refactored a month ago, and so on. This means that microservices are at very different maturity levels.
• As the number of microservices keeps growing, so does the number of tests needed for coverage.

Why conventional testing is not enough

The conventional approach to testing involves heavy unit testing on local boxes and maintains one or more test environments with all microservices. These are usually called staging environments. Teams run integration, contract, and other tests on the staging environment, making it the primary test area. After comprehensive testing on staging, teams promote the microservice to production. Once it reaches production, very little or no testing is done.

(The terminologies used here such as unit tests, integration tests, and contract tests are defined here and here.)

What is Mockers

Road ahead