liftbridge-io / go-liftbridge

Go client for Liftbridge. https://github.com/liftbridge-io/liftbridge
Apache License 2.0
66 stars 18 forks source link

Use map to store mock responses in tests #88

Closed LaPetiteSouris closed 3 years ago

LaPetiteSouris commented 3 years ago

Context

The current test behavior stores mock responses as an array in the mock API struct


type mockAPI struct {
    mu                        sync.Mutex
    responses                 []interface{}
....
}

This does not differentiate the responses of different rpc endpoints. Thus, in order to simulate different scenarios, the order in which the mock responses are stored is important.

In my opinion, the mock API should be:

  1. Deterministic : The rpc should returns mocked result consistently, regardless of how we store the mock responses' order

  2. Idempotent: The mock endpoint can be hit multiple times and still expect to return same results. It would be a bit easier to debug tests

  3. Isolate: responses of one mock rpc endpoint should not affect the mock response of other endpoint.

Changes proposed in the PR

  1. responses should be a map, with key of the map is the name of the rpc endpoint.

  2. Each endpoint should have its own method to set up its mock response, just like what is happening now with error mocking:

func (m *mockAPI) SetupMockSetStreamReadonlyError(err error) {
    m.mu.Lock()
    defer m.mu.Unlock()
    m.setStreamReadonlyErr = err
}
  1. Add a flag called autoClearError to indicate whether the mock API should clear mock error automatically or not . This behavior is practical for scenarios where retry is used. By default , it is deactivated.

Please let me know what do you think about this.