top of page

Own Your Code, Own Your Quality:

Automated Integration Testing for Developers


Problem: The Integration Testing Gap in Fast-paced Development

Modern developers face a constant struggle: balancing rapid feature development with a stable and scalable infrastructure. This challenge becomes even more pronounced when dealing with complex systems that include:

  • Support million/billions of users: The infrastructure needs to handle massive user bases efficiently.

  • Leverage ever-increasing computing power: The system must keep pace with advancements in computational capabilities.

  • Manage a vast and evolving codebase: Modern applications have large codebases that are constantly changing.

While unit testing plays a crucial role in verifying internal service logic, it falls short when it comes to ensuring seamless communication between different services. Traditional integration testing tools often require significant manual setup, making them cumbersome and hindering the development process. This creates a gap in the testing process, potentially leading to integration issues that can be costly to fix later in the development cycle.

Why Existing Solutions Weren't Enough:

Developers needed a better way to bridge this gap. Unit testing frameworks, while valuable, couldn't address the complexities of service interactions. Existing integration testing solutions often lacked the ease of use and automation needed for rapid development cycles.

The HyperTest Solution:

HyperTest has developed a unique approach to automatically generate and refresh mocks that efficiently test code and its dependencies, ensuring seamless integration and functionality validation.

HyperTest sets up as an SDK on any backend service (like an APM). It builds a trace for all the requests that hit the service with its outbound calls (for mocking). The correct behavior of the service is tested for regressions automatically when it undergoes a change.

 System Architect
System Architect

HyperTest Record and Replay (Test) Mode:

Record Mode

  • During the record phase, all requests hitting a service (SUT) are monitored, including all interactions between its components. This involves inputs, responses, and all outgoing calls. The recorded interactions can include function calls, network requests, message exchanges, or database queries.

  • HyperTest’s SDK sits directly on top of the SUT and captures the complete flow of actions that the SUT follows to give back the response.

  • Most of the common scenarios involve the SUT communicating with databases, downstream services, or sometimes any external third-party APIs or cloud services to generate the desired response for a specific request.

  • The service response and the outgoing calls in the record mode are treated as the baseline behavior of the service.

Test Mode

  • Devs run HyperTest in test mode when a new change is ready. In this mode, the requests captured in the record phase are executed to generate the actual response of the service at that time by mocking away the dependencies.

  • If the response changes due to modifications in status codes, content type, schema, data, and so on, HyperTest reports a regression.

  • Mocking away dependencies ensures that actual calls to the database and other downstream components are not made in test mode. Instead, the previously captured requests and responses are used, completely eliminating the need to keep the dependencies available for testing.

  • When these tests are run through HyperTest CLI, they generate a code coverage report highlighting covered and uncovered code paths.

Testing Stateful flows without managing test data

  • HyperTest's great value lies in giving teams the ability to test stateful applications without needing to create or manage test data.

  • Ability to intelligently generate and refresh mocks gives it the capability to test the application exactly in the state it needs to be.

To illustrate this, let's consider testing the sign-up functionality. Two possible scenarios can occur:

1.If a user signs up with an email address that has not been registered before, a new account needs to be created.

2.Alternatively, if a user already exists with the same email address, the application should respond with the message "the user already exists."

HyperTest SDK will record both of these flows from the traffic, i.e., a new user trying to register and an existing user trying to register (negative flow).

In test mode, when HyperTest runs both scenarios, it will have the recorded response from the database for both, testing them in the right state to report a regression if either of the behaviors regresses.

bottom of page