Skip to main content

Mocks

Tesmon provides a range of powerful mocking capabilities, with HTTP mock being one of the initial features. These mocking capabilities allow you to simulate different scenarios during test execution, enabling you to create comprehensive test cases and validate your system's behavior under various conditions.

With Tesmon, you can define precise match conditions, customize responses, forward requests to real services, simulate errors, and more. These features give you the flexibility to mimic complex interactions and thoroughly test your system.

Your mocks are handled with utmost privacy and security in Tesmon. All the mock data stays within your own environment, and Tesmon does not have access to or visibility into your mocks.

HTTP mock​

Response​

Response functionality allows you to define customized responses for your mocks. You can specify the status code, headers, and response body to simulate different scenarios during testing, ensuring accurate validation of your system's behavior.

Use Case: Simulating Successful Responses

  • Scenario: You want to simulate successful responses from a specific endpoint of a microservice to ensure that your system handles the expected behavior correctly.
  • Implementation: Configure a response mock for the desired endpoint, setting the appropriate status code, headers, and response body. This allows you to verify how your system handles the expected responses and performs the necessary operations based on them.

Use Case: Testing Error Handling

  • Scenario: You need to test the error handling capabilities of your system when it encounters specific error conditions from an API.
  • Implementation: Define an error response mock for the corresponding endpoint, specifying the desired error status code and an appropriate error message. This allows you to validate the error handling logic of your system and ensure that it responds appropriately to different error scenarios.

Here's an example of a mock configuration with a custom response:

match:
  method: POST
  path: /api/products
response:
  status: 201
  headers:
    Content-Type: application/json
  body:
    message: Product created successfully
    productId: "12345"

In this example, when a POST request is made to /api/products, the mock will respond with a 201 status code, set the Content-Type header to "application/json", and provide a JSON response body containing a message and the newly created product's ID.

Forward​

Forward functionality allows you to proxy requests to a real service when the specified conditions don't match the defined mocks. This is especially useful when you want to mock specific endpoints while forwarding all other requests to the actual service.

Use Case: Seamless Integration with External Services

  • Scenario: Your microservice depends on an external service that may not be available during testing or development.
  • Implementation: Set up a forward mock to forward all the requests from your microservice to the actual external service, except for the specific endpoint that is not available. By doing so, your microservice can seamlessly interact with the external service for all other endpoints, allowing you to test the integration and functionality of your system.

Use Case: Mocking Specific Endpoints during Development

  • Scenario: Your microservice is dependent on another microservice that is currently building a new endpoint that is not yet available for integration.
  • Implementation: Configure a forward mock to forward all requests from your microservice to the dependent microservice, except for the specific endpoint that is still under development. Mock the response for the in-progress endpoint, allowing you to isolate and test the integration of your microservice with the new endpoint without affecting other functionalities.

Here's an example of a mock configuration with a forward setup:

match:
  path: /api/orders
forward:
  host: http://actual-service.com
  port: 8080

In this scenario, all requests to /api/orders will be forwarded to the http://actual-service.com host on port 8080. This ensures that the mock only applies to the /api/orders endpoint, while all other requests are seamlessly forwarded to the real service.

Error​

Simulate errors by configuring the error property in a mock. You can define specific error scenarios, such as dropping the connection or returning invalid response bytes, allowing you to test error handling and response validation in your system.

Use Case: Simulating Unavailable Services

  • Scenario: You want to simulate scenarios where certain services or endpoints are unavailable due to maintenance, downtime, or other reasons.
  • Implementation: Set up an error mock for the unavailable services or endpoints, defining the appropriate status code and error message. This allows you to test how your system handles such unavailability and implements any fallback or error recovery mechanisms.

Here's an example of a mock configuration that drops the connection:

match:
  method: GET
  path: /api/users
  query:
    search: error
error:
  dropConnection: true

In this example, the mock is set up to match GET requests to /api/users with a query parameter search equal to "error". When such a request is made, the mock will drop the connection without sending any response.

Here's an example of a mock configuration that returns invalid response bytes:

match:
  method: GET
  path: /api/users
  query:
    search: error
error:
  responseBytes: "eQqmdjEEoaXnCvcK6lOAIZeU+Pn+womxmg=="

In this example, the mock is set up to match GET requests to /api/users with a query parameter search equal to "error". When such a request is made, the mock will respond with the specified sequence of bytes as the response, which may be an invalid response.

These examples demonstrate how you can configure error actions in Tesmon to simulate different error scenarios and observe how your system handles them.