Consumer-Driven-Contract-Testing-Sample

This project consists of three microservices that interact with each other to handle an OTP (One Time Password) generation and notification system. The three services are:

• OTP Service (otp-svc)
• User Service (user-svc)
• Notification Service (notify-svc)

1. OTP Service (otp-svc)

This service is responsible for generating and serving OTPs, as well as providing the status of the OTP process.

Endpoints:

• POST /otp:
  • Purpose: Generates an OTP and logs the request body received.
  • Response: Returns a JSON object containing the message "OTP generated" and the request body.

  {
  "message": "OTP generated",
  "explanation": "OTP is generated and sent to user",
  "requestBody": { ... }
  }
  

• GET /otp:
  • Purpose: Retrieves a hardcoded OTP for simplicity.
  • Response: Returns a JSON object with the OTP and its validity status.

  {
  "otp": "123456",
  "valid": true
  }
  

• GET /otp-status:
  • Purpose: Provides the status of the OTP process.
  • Response: Returns the status of OTP delivery.

  {
  "status": "OTP sent"
  }
  

How it interacts:

This service acts as the OTP provider. Other services request an OTP from here or check the OTP status.

2. User Service (user-svc)

This service interacts with the OTP service to request and retrieve OTPs, as well as with the Notification service to check the notification status.

Endpoints:

• POST /request-otp:
  • Purpose: Sends a request to the OTP service to generate an OTP.
  • Interaction: Makes a POST request to otp-svc's /otp endpoint with the body received from the client.
  • Response: Returns a confirmation that the OTP request was sent, along with the response from otp-svc.

  {
  "message": "OTP requested",
  "otpResponse": { ... }
  }
  

• GET /get-otp:
  • Purpose: Retrieves the generated OTP from otp-svc.
  • Interaction: Makes a GET request to otp-svc's /otp endpoint.
  • Response: Returns the retrieved OTP and its status.

  {
  "message": "OTP retrieved",
  "otp": { "otp": "123456", "valid": true }
  }
  

• GET /notification-status:
  • Purpose: Checks the status of the notification from the notify-svc.
  • Interaction: Makes a GET request to notify-svc's /notification-status endpoint.
  • Response: Returns the notification status from notify-svc.

  {
  "message": "Notification status retrieved",
  "notifyStatus": { "status": "Notification service is running" }
  }
  

How it interacts:

This service communicates with the OTP service to request and retrieve OTPs, and with the Notification service to check the status of notifications.

3. Notification Service (notify-svc)

This service is responsible for sending notifications about the OTP status.

Endpoints:

• GET /notify:
  • Purpose: Requests the OTP status from the otp-svc and sends a notification.
  • Interaction: Makes a GET request to otp-svc's /otp-status endpoint to retrieve the OTP status.
  • Response: Returns the OTP status received from otp-svc.

  {
  "message": "Notification sent",
  "otpStatus": { "status": "OTP sent" }
  }
  

• GET /notification-status:
  • Purpose: Provides the status of the Notification service.
  • Response: Returns a message indicating that the Notification service is running.

  {
  "status": "Notification service is running"
  }
  

How it interacts:

This service requests OTP status from the otp-svc and notifies the user about the OTP status. It also provides a status check for the notification system.

Interaction Workflow

1. The User Service (user-svc) receives a request to generate an OTP via /request-otp and forwards this request to the OTP Service (otp-svc).
2. The OTP Service (otp-svc) processes the request, generates an OTP, and returns a response.
3. The User Service (user-svc) can retrieve the OTP from the OTP Service (otp-svc) via the /get-otp endpoint.
4. The User Service can also check the status of the Notification Service by calling /notification-status on the Notification Service (notify-svc).
5. The Notification Service (notify-svc) interacts with the OTP Service (otp-svc) to retrieve the OTP status via /notify and sends a notification.

Running the Services

• Start the OTP Service on port 3001.
• Start the Notification Service on port 3002.
• Start the User Service on port 3000.

Each service runs independently but interacts with each other to complete the OTP and notification workflow.

Recording Test Cases and Mocks with Keploy

You can record test cases and mocks for these services using the keploy command. To record test cases and mocks, follow these steps:

1. Install Keploy on your machine if you haven't already.
2. Run the keploy record command to record interactions of the otp service go to otp-svc and write:

   keploy record -c "node index.js"

3. Send the requests of it from the curls file in VirtualCPR folder
4. Test cases will be recorded and be put inside otp-svc
5. Do the same for notify-svc and user-svc

If you don't want to record new test cases and mocks, there are already existing recorded test cases and mocks available in the repository, which can be used directly without re-recording.

Generating OpenAPI schemas of Test cases and Mocks with Keploy

1. Run the keploy contract command to generate OpenAPI Schemas for each service of the three:

   keploy contract generate 

Consumer Driven Testing

1. Run the keploy contract test command to run consumer driven contract testing:

   keploy contract test --driven "consumer" 

Differences & Summary

1. Now you will see the differences between each mock and it's ideal test case.