• A lightweight declarative HTTP mocking framework in Golang
  • Introduction
  • Features
  • How it works
  • How to use in unit test for Golang
    • Prerequisites
    • Install
    • Usage
  • How to use in integration test
    • Deploy Rio as a stand-alone service
    • Change the root url configuration of the external to mock server
    • Perform manual test case
    • Write an automation test cases
  • Request Matching
    • Match by method and url
    • Match by query parameter
    • Match by cookies
    • Match by request body
      • JSON Path
      • XML Path
      • Multipart
      • URL Encoded Form (application/x-www-form-urlencoded)
    • Matching Operators
  • Response Definition
    • Status Code, Cookies, Header
    • Response body
      • JSON
      • XML
      • HTML
      • Stream/Binary
    • Redirection
    • Reserve proxy and recording
    • Mock a download API
  • Create stubs using Postman
    • JSON Format
    • YAML
  • Advance Features
    • Support priority response
    • Delay response
    • Deactivate stub when matched
    • Namespace
    • Dynamic response
  • Mocking GRPC
    • Define a proto
    • Define stub
    • Mocking GRPC error response
    • Change the root url to rio
  • How to deploy
    • Setup database
    • Deploy file storage
      • Use S3
      • Use GCS
    • Deploy HTTP mock server
    • Deploy GRPC mock server
    • Configure cache
  • Contribution
    • Run test
    • Commit Changes

Rio is a declarative HTTP mocking library for unit test in Golang and HTTP/gPRC mock server for integration test. Using the same framework for both kind of tests can help to share stub definition schema or codes between developers and testers easily. This framework has been used for thousands of test cases internally for a long time ago, but it just has been published recently (Rio is a variant of parrot)

• Fast, simple and fluent API for unit test in Golang
• DSL in YAML/JSON format for stub declarations
• Supports wide-range response types (html, xml, json and binary)
• Can be deployed as mock server (HTTP and gRPC) for integration test
• Supports persistent stubs to database with caching to improve performance
• Flexible for matching request by method, URL params, headers, cookies and bodies
• Dynamic response with go-template
• Automatically generates stubs with reserve proxy mode
• Ability to run tests in parallel to improve speed
• Support SDK in Golang and TypeScript/Javascript

Suppose that we want to test a function that calls API and parse the response data as the following example

func CallAPI(ctx context.Context, rootURL string, input map[string]interface{}) (map[string]interface{}, error) {
	bodyBytes, err := json.Marshal(input)
	if err != nil {
		return nil, err
	}

	req, err := http.NewRequestWithContext(ctx, http.MethodPost, rootURL "/animal", bytes.NewReader(bodyBytes))
	if err != nil {
		return nil, err
	}

	req.Header.Set("Content-Type", "application/json")
	res, err := http.DefaultClient.Do(req)
	if err != nil {
		return nil, err
	}

	data := map[string]interface{}{}
	decoder := json.NewDecoder(res.Body)
	if err := decoder.Decode(&data); err != nil {
		return nil, err
	}

	return data, nil
}

Golang 1.18

go get github.com/hungdv136/rio@latest

No deployment is required for unit test

Write unit test with Golang

func TestCallAPI(t *testing.T) {
	t.Parallel()

	ctx := context.Background()
	server := rio.NewLocalServerWithReporter(t)

	t.Run("success", func(t *testing.T) {
		t.Parallel()

		animalName := uuid.NewString()
		returnedBody := map[string]interface{}{"id": uuid.NewString()}

		require.NoError(t, rio.NewStub().
			// Verify method and path
			For("POST", rio.EndWith("/animal")).
			// Verify if the request body is composed correctly
			WithRequestBody(rio.BodyJSONPath("$.name", rio.EqualTo(animalName))).
			// Response with 200 (default) and JSON
			// Body can be map, struct or JSON string
			WillReturn(rio.JSONResponse(returnedBody)).
			// Submit stub to mock server
			Send(ctx, server))

		input := map[string]interface{}{"name": animalName}
		resData, err := CallAPI(ctx, server.GetURL(ctx), input)
		require.NoError(t, err)
		require.Equal(t, returnedBody, resData)
	})

	t.Run("bad_request", func(t *testing.T) {
		t.Parallel()

		animalName := uuid.NewString()

		require.NoError(t, rio.NewStub().
			// Verify method and path
			For("POST", rio.EndWith("/animal")).
			// Verify if the request body is composed correctly
			WithRequestBody(rio.BodyJSONPath("$.name", rio.EqualTo(animalName))).
			// Response with status 400 and empty body JSON
			WillReturn(rio.NewResponse().WithStatusCode(400)).
			// Submit stub to mock server
			Send(ctx, server))

		input := map[string]interface{}{"name": animalName}
		resData, err := CallAPI(ctx, server.GetURL(ctx), input)
		require.Error(t, err)
		require.Empty(t, resData)
	})
}

Examples

Suppose that we want to test (manual or automation) an API that calls an external API by simulating a mock response for that external API. It can help us to create stable tests by isolating our test suites with external systems

Golang, TypeScript, Postman can be used to define and submit stubs to mock server. This repository illustrates how to use Rio to write integration tests in Javascript/TypeScript

See deploy. After deployed, Rio can be accessed by other services via a domain, for example http://rio-domain

Go to ENV management system to change the root URL to the mock server with the format: http://rio-domain/echo (Must include /echo at the end)

1. Use Postman to submit stubs
2. Use Postman to perform manual test with your API

1. Create a new server

This struct is used to connect with the remote server that we have deployed above, so we should provide the root url of that mock server when initializing the remote server struct

server := rio.NewRemoteServer("http://rio-server")

import { Server } from 'rio-ts-sdk'
server := Server('http://rio-server')

2. Define a stub

resData :=types.Map{"data": uuid.NewString(),"verdict": "success"}
stub := rio.NewStub().
		For("GET", rio.Contains("animal/create")).
		WithHeader("X-REQUEST-ID", rio.Contains("<x-request-id>")).
		WithQuery("search_term", rio.EqualTo("<search-value>")).
		WithCookie("SESSION_ID", rio.EqualTo("<cookie-value>")).
		WillReturn(rio.JSONResponse(resData)).
    Send(ctx, server)

import { Stub, Rule, JSONResponse } from 'rio-ts-sdk'

resData :={data: uuidv4(), verdict: "success"};
stub := new Stub("GET", Rule.contains("animal/create"))
  .withHeader("X-REQUEST-ID", Rule.contains('<x-request-id>'))
  .withQuery("search_term", Rule.equalsTo('<search-value>'))
  .withCookie("SESSION_ID", Rule.equalsTo('<cookie-value>'))
  .willReturn(JSONResponse(resData))
  .send(ctx, server);

In the above example, the stub will be pushed to remote server via stub/create_many API. This should be done before performing a request to the test target service. Since the root url of the external service is switched to Rio service, the request will be routed to Rio service. Once a request comes, a generic handler in remote server will validate the following information

• Validate method GET
• Validate whether request's path contains animal/create
• Validate query string search_term whether its value contains a predefined value
• Validate X-Request-ID whether its value equals to a predefined value
• Validate cookie SESSION_ID whether its value equals to a predefined value
• If these conditions are matched, then return with predefined response

This is to verify incoming requests against predefined stubs. If all rules are matched, then the predefined response of matched stub will be responded

NewStub().For("GET", Contains("/helloworld"))

new Stub("GET", Rule.contains("/helloworld"))

{
  "request": {
    "method": "GET",
    "url": [{
      "name": "contains",
      "value": "/helloworld"
    }]
  }
}

NewStub().WithQuery("search_term", NotEmpty())

new Stub("GET", Rule.contains("/helloworld"))
  .withQuery("search_term", Rule.notEmpty())

{
  "request": {
    "query": [{
      "field_name": "search_term",
      "operator": {
        "name": "not_empty"
      }
    }]
  }
}

NewStub().WithCookie("SESSION_ID", EqualTo("expected cookie value"))

new Stub("GET", Rule.contains("/helloworld"))
  .withCookie("SESSION_ID", Rule.equalsTo("expected cookie value"))

{
  "request": {
    "cookie": [{
      "field_name": "SESSION_ID",
      "operator": {
        "name": "equal_to",
        "value": "expected cookie value"
      }
    }]
  }
}

NewStub().WithRequestBody(BodyJSONPath("$.name"), NotEmpty())

new Stub('GET', Rule.endWith('/helloworld'))
  .withRequestBody(
    JSONPathRule("$.name", Rule.notEmpty()),
    JSONPathRule("$.count", Rule.equalsTo(3000))
  )

{
  "request": {
    "body": [{
      "content_type":  "application/json",
      "operator": {
        "name": "not_empty"
      },
      "key_path": "$.name"
    }] 
  }
}

NewStub().WithRequestBody(BodyXMLPath("//book/title"), NotEmpty())

{
  "request": {
    "body": [{
      "content_type":  "text/xml",
      "operator": {
        "name": "not_empty"
      },
      "key_path": "//book/title"
    }] 
  }
}

NewStub().WithRequestBody(MultipartForm("field_name"), NotEmpty())

new Stub('GET', Rule.endWith('/helloworld'))
  .withRequestBody(
    MultiPartFormRule("field_name", Rule.notEmpty())
  )

{
  "request": {
    "body": [{
      "content_type":  "multipart/form-data",
      "operator": {
        "name": "not_empty"
      },
      "key_path": "field_name"
    }] 
  }
}

NewStub().WithRequestBody(URLEncodedBody("CustomerID", EqualTo("352461777")))

new Stub('GET', Rule.endWith('/helloworld'))
  .withRequestBody(
    URLEncodedBodyRule("CustomerID", Rule.equalsTo("352461777"))
  )

{
  "request": {
    "body": [{
      "content_type":  "application/x-www-form-urlencoded",
      "operator": {
        "name": "equal_to",
        "value": "352461777"
      },
      "key_path": "CustomerID"
    }] 
  }
}

See operator for supported operators which can be used for any matching types including method, url, headers. cookies and bodies

Response can be defined using fluent functions WithXXX (Header, StatusCode, Cookie, Body) as the following example

rio.NewResponse().WithStatusCode(400).WithHeader("KEY", "VALUE")

new StubResponse().withStatusCode(400).withHeader("KEY", "VALUE")

The below are convenient functions to create response with common response content types

// JSON 
rio.JSONReponse(body)

// XML
rio.XMLReponse(body)

// HTML
rio.HTMLReponse(body)

// JSON 
JSONReponse({fieldName: 'value'})

// XML
XMLReponse(`<xml></xml>`)

// HTML
HTMLReponse(`<html></html>`)

resStub := NewResponse()
  .WithHeader("X-REQUEST-HEADER", "HEADER_VALUE")
  .WithStatusCode(400)
  .WithCookie("KEY", "VALUE")

NewStub().WithReturn(resStub)

resStub := new StubResponse()
  .withHeader("X-REQUEST-HEADER", "HEADER_VALUE")
  .withStatusCode(400)
  .withCookie("KEY", "VALUE")

new Stub('GET', Rule.contains('/path')).withReturn(resStub)

{
  "response": {
    "body": {
      "key": "value"
    },
    "cookies": [{
      "name": "SESSION_ID",
      "value": "4e1c0c4d-b7d4-449e-882e-f1be825f1d27",
      "expired_at": "2023-01-07T12:26:01.59694 07:00"
    }],
    "header": {
      "Content-Type": "application/json"
    },
    "status_code": 200
  }
}

Use JSONResponse to construct response with JSON (parameter can be map or struct)

err := NewStub().For("POST", Contains("animal/create")).
    WillReturn(JSONResponse(types.Map{"id": animalID})).
    Send(ctx, server)

await new Stub("POST", Rule.contains("animal/create"))
  .willReturn(JSONResponse({"id": animalID})).
  .send(server)

{
  "response": {
    "status_code": 200,
    "header": {
      "Content-Type": "application/json"
    },
    "body": {
      "key": "value"
    }
  }
}

Use XMLResponse to construct response with XML

err := NewStub().For("POST", Contains("animal/create")).
    WillReturn(XMLResponse(structVar)).
    Send(ctx, server)

await new Stub("POST", Rule.contains("animal/create"))
  .willReturn(XMLResponse(`<xml><animal name="bird"/></xml>`)).
  .send(server)

{
  "status_code": 200,
  "body": "PGh0bWw PGh0bWw ",
  "header": {
    "Content-Type": "text/xml"
  }
}

With XML data type, content must be encoded to base64 before submit stub as JSON directly to API. If you want to use raw string, submit with YAML format instead. See YAML for example

err := NewStub().For("POST", Contains("animal/create")).
    WillReturn(HTMLResponse("<html></html>")).
    Send(ctx, server)

await new Stub("POST", Rule.contains("animal/create"))
  .willReturn(HTMLResponse(`<html> content <html>`)).
  .send(server)

{
  "status_code": 200,
  "body": "PGh0bWw PGh0bWw ",
  "header": {
    "Content-Type": "text/html"
  }
}

With HTML data type, content must be encoded to base64 before submit stub as JSON to mokc API. Go and TS SDK handles this out of the box. If you want to use raw string, submit with YAML format instead. See YAML for example

We should upload file to server, then assign file id and appropriate content type to response. This also works for any other response types such as JSON, HTML, XML, ...

server.UploadFile(ctx, fileID, fileBody)
NewStub().WithReturn(NewResponse().WithFileBody(fileID))

const server = Server('http://<mock-server>');
const fileID = await server.uploadFile('/<path/to/file>');

new Stub().withReturn(new StubResponse().withFileBody(fileID))

{
  "response": {
    "status_code": 200,
    "body_file": "<file_id>",
    "header": {
      "Content-Type": "<content-type>"
    }
  }
}

This is to redirect request to another url

resStub := NewResponse().WithRedirect("https://redirect_url.com")
NewStub().WithReturn(resStub)

resStub := NewResponse().withRedirect("https://redirect_url.com");
new Stub().withReturn(resStub);

{
  "response": {
    "status_code": 307,
    "header": {
      "Location": "https://redirect_url.com"
    }
  }
}

If we want to communicate with real service and record the request and response, then we can enable recording as the following

• target_url is the root url of the real system
• target_path is optional. If not provided, then the same relative path from incoming request is used

rio.NewStub().
		ForAny(rio.Contains("reverse_recording/animal/create")).
		WithTargetURL(targetURL).
		WithEnableRecord(true)

new Stub('', Rule.contains("reverse_recording/animal/create"))
  .withTargetURL(targetURL)
  .withEnableRecord(true)

{
  "proxy": {
    "target_url": "https://destination",
    "enable_record": true
  }
}

The server will create a new inactive stub into database as the recorded result. This is very helpful for the 1st time we want to simulate the response for a service

1. Create an appropriate server (local for unit test or remote for integration test)

server := NewRemoteServer("http://mock-server")

2. Upload file

b, err := os.ReadFile(filePath)
require.NoError(t, err)

fileID, err = server.UploadFile()
require.NoError(t, err)

We can upload file using rest for integration test POST {rio-domain}/upload

3. Create a stub

resStub := NewResponse().WithFileBody("image/jpeg", fileID)
err := NewStub().For("GET", Contains("animal/image/download")).WillReturn(resStub).Send(ctx, server)

{
  "response": {
    "body_file": "<uploaded_file_id",
    "status_code": 200
  }
}

4. Perform download request

req := http.NewRequest(http.MethodGet, server.GetURL(ctx) "/animal/image/download", nil)
res, err := http.DefaultClient.Do(req)
require.NoError(t, err)
require.Equal(t, http.StatusOK, res.StatusCode)
defer res.Body.Close()
// Read response body and assert

See Swagger for API specifications

The stubs (matching rules and the expected response) can be created through Rest API stubs/create_many, the below is example of body payload

{
  "stubs": [
    {
      "active": true,
      "id": 1,
      "namespace": "",
      "request": {
        "body": [
          {
            "content_type":"application/json",
            "key_path": "$.book.type",
             "operator": {
              "name": "equal_to",
              "value": "How to write test in Golang"
            }
          }
        ],
        "cookie": [
          {
            "field_name": "SESSION_ID",
            "operator": {
              "name": "equal_to",
              "value": "27a6c092-3bdc-4f46-b1fb-1c7c5eea39e0"
            }
          }
        ],
        "header": [
          {
            "field_name": "X-REQUEST-ID",
            "operator": {
              "name": "equal_to",
              "value": "f5dcaabc-caac-4c5e-9e06-6b1e935b756d"
            }
          }
        ],
        "method": "GET",
        "query": [
          {
            "field_name": "search_term",
            "operator": {
              "name": "equal_to",
              "value": "4e1c0c4d-b7d4-449e-882e-f1be825f1d27"
            }
          }
        ],
        "url": [
          {
            "name": "contains",
            "value": "animal/create"
          }
        ]
      },
      "response": {
        "body": {
          "key": "value"
        },
        "body_file": "",
        "cookies": [{
          "name": "SESSION_ID",
          "value": "4e1c0c4d-b7d4-449e-882e-f1be825f1d27",
          "expired_at": "2023-01-07T12:26:01.59694 07:00"
        }],
        "header": {
          "Content-Type": "application/json"
        },
        "status_code": 200
      },
      "settings": {
        "deactivate_when_matched": false,
        "delay_duration": 0
      },
      "weight": 0
    }
  ]
}

If the response body is not JSON such as XML, or HTML. It is hard to use submit stub with JSON format since JSON does not support multiple lines. In that case, we should use YAML as the following example. Remember to add Content-Type=application/x-yaml (This is header of submit request, it is not header of the expected response)

stubs:
  - active: true
    namespace: ""
    request:
      body:
        - content_type: application/json
          key_path: $.book.type
          operator:
            name: equal_to
            value: How to write test in Golang
      cookie:
        - field_name: SESSION_ID
          operator:
            name: equal_to
            value: 27a6c092-3bdc-4f46-b1fb-1c7c5eea39e0
      header:
        - field_name: X-REQUEST-ID
          operator:
            name: equal_to
            value: f5dcaabc-caac-4c5e-9e06-6b1e935b756d
      method: GET
      query:
        - field_name: search_term
          operator:
            name: equal_to
            value: 4e1c0c4d-b7d4-449e-882e-f1be825f1d27
      url:
        - name: contains
          value: animal/create
    response:
      template:
        status_code: 200
        header: 
          Content-Type: text/html
        body: >
            <html>
              This is HTML body type
            </html>
    settings:
      deactivate_when_matched: false
      delay_duration: 0s
    weight: 0

All these features are supported in Go and TypeScript SDK with the same function names

Sometimes, we want the server to return a fallback response if there is no stub are fully matched with the expectation. In this case, we should submit two different stubs to the mock server. Rio will get the stub with highest weight first, if the weight is not specified, the latest stub will be used

highPriority := rio.NewStub().
    For("GET", rio.Contains("animal/create")).
    WithHeader("X-REQUEST-ID", rio.Contains(uuid.NewString())).
    WithQuery("search_term", rio.EqualTo(uuid.NewString())).
    WithCookie("SESSION_ID", rio.EqualTo(uuid.NewString())).
    WithWeight(10).
    WillReturn(rio.NewResponse().WithBody(rio.MapToJSON(resData))).
    Send(server)

lowPriority := NewStub().
    For("GET", Contains("animal/image/download")).
    WithWeight(1).
    WillReturn(resStub).
    Send(ctx, server)

{
   "weight": 10
}

It is sometimes we want to simulate slow response API. Rio supports this feature by set delay duration

NewStub().For("GET", Contains("animal/create")).ShouldDelay(3 * time.Second)

new Stub("GET", Rule.contains("animal/create")).shouldDelay(3000)

{
  "settings": {
    "delay_duration": "3000000000"
  }
}

This is to disable the matched stub, it is not used for the next request. In the following example, the first request will return the first stub with higher weight, then that stub is not available for the next request anymore

NewStub().For("GET", Contains("animal/create")).ShouldDeactivateWhenMatched().WithWeight(2)
NewStub().For("GET", Contains("animal/create")).ShouldDeactivateWhenMatched().WithWeight(1)

{
  "settings": {
    "deactivate_when_matched": true
  }
}

The namespace can be used to separate data between test case. This is helpful when a single mock server is used for many features and projects. Use this pattern as the root url http://rio.mock.com/<namespace>/echo. For example, we want to separate test stubs for payment_service and lead service, then set the root url for those service as below

• Payment Service Root URL: http://rio.mock.com/payment_service/echo

• Lead Service Root URL: http://rio.mock.com/lead_service/echo

If this url is used http://rio.mock.com.com/echo, then default namespace (empty) will be used

The dynamic response uses the Go template to generate the response body programatically. The template is a string in YAML format as the following example. Since the JSON does not support multiple lines input, we should submit stubs in YAML format by providing the request body as the following example. Also, we should set the Content-Type header to application/x-yaml

Notes: While this is a powerful feature, we don't recommend to use this feature in the unit test and automation integration test. Because, it is more flexible and easier to debug when building the response using native language that we use to write the test. This template should use for manual test only

For supported function in Go template, see http://masterminds.github.io/sprig/

Avaliable Variables

• Request, can be access as {{ .Request.<Go-Field-Name> }}
• JSONBody is parsed body in JSON format, can be used in go template as {{ .JSONBody.<json_field_parent>.<json_field_child> }}

stubs:
  - active: true
    namespace: ""
    request:
      body:
        - content_type: application/json
          key_path: $.book.type
          operator:
            name: equal_to
            value: How to write test in Golang
      cookie:
        - field_name: SESSION_ID
          operator:
            name: equal_to
            value: 27a6c092-3bdc-4f46-b1fb-1c7c5eea39e0
      header:
        - field_name: X-REQUEST-ID
          operator:
            name: equal_to
            value: f5dcaabc-caac-4c5e-9e06-6b1e935b756d
      method: GET
      query:
        - field_name: search_term
          operator:
            name: equal_to
            value: 4e1c0c4d-b7d4-449e-882e-f1be825f1d27
      url:
        - name: contains
          value: animal/create
    response:
      template:
        script_schema_type: yaml
        script: >
            status_code: 200
            
            cookies: 
                {{ range $cookie := .Request.Cookies }}
                - name: {{ $cookie.Name }}
                  value: {{ $cookie.Value }}
                {{end}}

            headers:
                X-REQUEST-ID: {{ .Request.Header.Get "X-REQUEST-ID"}} 
            
            body: >
                {
                    "encrypted_value": "{{ encryptAES "e09b3cc3b4943e2558d1882c9ef999eb" .JSONBody.naked_value}}"
                }
    settings:
      deactivate_when_matched: false
      delay_duration: 0s
    weight: 0

Example for template in TypeScript this file

Mocking grpc is mostly the same as mocking HTTP, the following are some minor differences. Currently, only Unary is supported. Even this gRPC mocking can be used with unit test, we recommend that we should not use it for unit test since it is not right way to do unit test with gPRC

• Compress protos of a target service and its own proto dependencies into a single compressed file with the same package structure
• Call API POST proto/upload to upload compressed file to the rio server. After uploaded proto file, the rest are the same as HTTP mocking

Define stub for grpc the same as for HTTP mock with the following differences

• method must be grpc as the following example
• status_code: Must follow grpc code. Default = 0 for success response. For details
• header: will be matched with request metadata (For example: X-REQUEST-ID)
• cookie and query are not supported in GRPC

{
  "request": {
    "method": "grpc",
    "url": [{
      "name": "equal_to",
      "value": "/offers.v1.OfferService/ValidateOffer"
    }]
  },
  "response": {
    "status_code": 0,
    "body": {
      "key": "value"
    },
    "header": {
      "Header-Name": "HEADER-VALUE"
    }
  }
}

The response body is in JSON format. You can enable proxy with recording or look at the generated proto structure to know the response structure

{
  "request": {
    "method": "grpc",
    "url": [{
      "name": "equal_to",
      "value": "/offers.v1.OfferService/ValidateOffer"
    }]
  },
  "response": {
    "status_code": 3,
    "error": {
      "message": "This is error message",
      "details": [{
        "type": "common.v1.CommonError",
        "value": {
          "verdict": "record_not_found"
        }
      }]
    }
  }
}

status_code: Must be greater than 0 details: Optional. This is to define detail of error. type: must be defined and its proto definitions must be included in the same compressed proto. value is a custom key value

Note that the root does not contains /echo/ as HTTP mock, also namespace is not supported yet

This is to deploy remote mock server. These steps are not required for unit test

Supported databases: MySQL or MariaDB

DB_SERVER=0.0.0.0:3306
DB_USER=<user>
DB_PASSWORD=<password>

If LocalStorageType is used then Rio can only be deployed with single instance. The GRPC and HTTP services must access to the same directory that is defined in ENV FILE_DIR. If we want to deploy Rio as a cluster with multiple instances, then GCS or S3 must be used as file storage

FILE_STORAGE_TYPE=s3
S3_ACCESS_KEY_ID=
S3_SECRET_ACCESS_KEY=
S3_REGION=ap-southeast-1

FILE_STORAGE_TYPE=gcs
GCS_CREDENTIALS_FILE=<credential-file-path>

This is required even we want to use GRPC mock only because HTTP server is not only for serving mock requests, but also contains a set of API for submitting stubs

This is optional. The GRPC is to serve mock GRPC requests. If you just want to use HTTP mock, then can skip this step

The below are default configuration for cache. If we want to change cache TTL or change cache strategy, then adjust the following env. Otherwise, can ignore these configurations

STUB_CACHE_TTL=1h
STUB_CACHE_STRATEGY=default

The default strategy cache stubs and protos in local memory and invalidate if there is any update/insert/delete in database. If we want to do performance testing, then can change STUB_CACHE_STRATEGY to aside

• Docker Compose: HTTP mock server

• Docker Compose GRPC: HTTP and gRPC mock servers

There are few integration tests in these packages internal/database, internal/api and internal/grpc those are integrated with real database. Follow the following step to setup environment and run tests

1. Install docker

2. Run the below command to setup database for testing

make dev-up

3. Run all tests

make test

4. To cleanup testing environment

make dev-down

Run the below command to format codes, check lint and run tests before commit codes

make all