top of page
HyperTest_edited.png

Automated Integration Testing for Developers




 

Problem: The Integration Testing Gap in Fast-paced Development


Developers of modern agile world struggle to release bug-free code fast and without risk because of lack of effective automation


Agile teams place a lot of importance on unit tests which are useful in checking business logic but fail to test the integration layer i.e. the dependencies between services, that constitute more than 50% of all production issues. This problem becomes more acute in apps with service oriented architecture where it is not uncommon for downstream changes to cause upstream failures. Rapid development and limited visibility on inter-service dependence is the root cause of all integration issues.


Inadequately tested code-base also adds technical debt over time that makes new development harder, forcing devs to spend excessive time fixing past issues which leads to dev burnout, low productivity and missing delivery deadlines.


Hence developers working on distributed systems in high speed environments need a new approach that can autonomously test new code changes with all its dependencies i.e. external services, 3rd party APIs, databases and message queues, right at source so that they can focus all their time on development.


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