0
Fork 0
mirror of https://codeberg.org/forgejo/forgejo.git synced 2024-12-23 07:43:18 -05:00
forgejo/modules/queue/mock/redisuniversalclient.go

344 lines
11 KiB
Go
Raw Normal View History

refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
// Code generated by MockGen. DO NOT EDIT.
// Source: code.gitea.io/gitea/modules/nosql (interfaces: RedisClient)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
//
// Generated by this command:
//
// mockgen -package mock -destination ./modules/queue/mock/redisuniversalclient.go code.gitea.io/gitea/modules/nosql RedisClient
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
//
// Package mock is a generated GoMock package.
package mock
import (
context "context"
reflect "reflect"
time "time"
redis "github.com/redis/go-redis/v9"
gomock "go.uber.org/mock/gomock"
)
// MockRedisClient is a mock of RedisClient interface.
type MockRedisClient struct {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
ctrl *gomock.Controller
recorder *MockRedisClientMockRecorder
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// MockRedisClientMockRecorder is the mock recorder for MockRedisClient.
type MockRedisClientMockRecorder struct {
mock *MockRedisClient
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// NewMockRedisClient creates a new mock instance.
func NewMockRedisClient(ctrl *gomock.Controller) *MockRedisClient {
mock := &MockRedisClient{ctrl: ctrl}
mock.recorder = &MockRedisClientMockRecorder{mock}
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return mock
}
// EXPECT returns an object that allows the caller to indicate expected use.
func (m *MockRedisClient) EXPECT() *MockRedisClientMockRecorder {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return m.recorder
}
// Close mocks base method.
func (m *MockRedisClient) Close() error {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "Close")
ret0, _ := ret[0].(error)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// Close indicates an expected call of Close.
func (mr *MockRedisClientMockRecorder) Close() *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Close", reflect.TypeOf((*MockRedisClient)(nil).Close))
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// DBSize mocks base method.
func (m *MockRedisClient) DBSize(arg0 context.Context) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "DBSize", arg0)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
ret0, _ := ret[0].(*redis.IntCmd)
return ret0
}
// DBSize indicates an expected call of DBSize.
func (mr *MockRedisClientMockRecorder) DBSize(arg0 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "DBSize", reflect.TypeOf((*MockRedisClient)(nil).DBSize), arg0)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// Decr mocks base method.
func (m *MockRedisClient) Decr(arg0 context.Context, arg1 string) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "Decr", arg0, arg1)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
ret0, _ := ret[0].(*redis.IntCmd)
return ret0
}
// Decr indicates an expected call of Decr.
func (mr *MockRedisClientMockRecorder) Decr(arg0, arg1 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Decr", reflect.TypeOf((*MockRedisClient)(nil).Decr), arg0, arg1)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// Del mocks base method.
func (m *MockRedisClient) Del(arg0 context.Context, arg1 ...string) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
varargs := []any{arg0}
for _, a := range arg1 {
varargs = append(varargs, a)
}
ret := m.ctrl.Call(m, "Del", varargs...)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// Del indicates an expected call of Del.
func (mr *MockRedisClientMockRecorder) Del(arg0 any, arg1 ...any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
varargs := append([]any{arg0}, arg1...)
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Del", reflect.TypeOf((*MockRedisClient)(nil).Del), varargs...)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// Exists mocks base method.
func (m *MockRedisClient) Exists(arg0 context.Context, arg1 ...string) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
varargs := []any{arg0}
for _, a := range arg1 {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
varargs = append(varargs, a)
}
ret := m.ctrl.Call(m, "Exists", varargs...)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// Exists indicates an expected call of Exists.
func (mr *MockRedisClientMockRecorder) Exists(arg0 any, arg1 ...any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
varargs := append([]any{arg0}, arg1...)
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Exists", reflect.TypeOf((*MockRedisClient)(nil).Exists), varargs...)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// FlushDB mocks base method.
func (m *MockRedisClient) FlushDB(arg0 context.Context) *redis.StatusCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "FlushDB", arg0)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
ret0, _ := ret[0].(*redis.StatusCmd)
return ret0
}
// FlushDB indicates an expected call of FlushDB.
func (mr *MockRedisClientMockRecorder) FlushDB(arg0 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "FlushDB", reflect.TypeOf((*MockRedisClient)(nil).FlushDB), arg0)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// Get mocks base method.
func (m *MockRedisClient) Get(arg0 context.Context, arg1 string) *redis.StringCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "Get", arg0, arg1)
ret0, _ := ret[0].(*redis.StringCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// Get indicates an expected call of Get.
func (mr *MockRedisClientMockRecorder) Get(arg0, arg1 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Get", reflect.TypeOf((*MockRedisClient)(nil).Get), arg0, arg1)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// HDel mocks base method.
func (m *MockRedisClient) HDel(arg0 context.Context, arg1 string, arg2 ...string) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
varargs := []any{arg0, arg1}
for _, a := range arg2 {
varargs = append(varargs, a)
}
ret := m.ctrl.Call(m, "HDel", varargs...)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// HDel indicates an expected call of HDel.
func (mr *MockRedisClientMockRecorder) HDel(arg0, arg1 any, arg2 ...any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
varargs := append([]any{arg0, arg1}, arg2...)
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "HDel", reflect.TypeOf((*MockRedisClient)(nil).HDel), varargs...)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// HKeys mocks base method.
func (m *MockRedisClient) HKeys(arg0 context.Context, arg1 string) *redis.StringSliceCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "HKeys", arg0, arg1)
ret0, _ := ret[0].(*redis.StringSliceCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// HKeys indicates an expected call of HKeys.
func (mr *MockRedisClientMockRecorder) HKeys(arg0, arg1 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "HKeys", reflect.TypeOf((*MockRedisClient)(nil).HKeys), arg0, arg1)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// HSet mocks base method.
func (m *MockRedisClient) HSet(arg0 context.Context, arg1 string, arg2 ...any) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
varargs := []any{arg0, arg1}
for _, a := range arg2 {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
varargs = append(varargs, a)
}
ret := m.ctrl.Call(m, "HSet", varargs...)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// HSet indicates an expected call of HSet.
func (mr *MockRedisClientMockRecorder) HSet(arg0, arg1 any, arg2 ...any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
varargs := append([]any{arg0, arg1}, arg2...)
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "HSet", reflect.TypeOf((*MockRedisClient)(nil).HSet), varargs...)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// Incr mocks base method.
func (m *MockRedisClient) Incr(arg0 context.Context, arg1 string) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "Incr", arg0, arg1)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// Incr indicates an expected call of Incr.
func (mr *MockRedisClientMockRecorder) Incr(arg0, arg1 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Incr", reflect.TypeOf((*MockRedisClient)(nil).Incr), arg0, arg1)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// LLen mocks base method.
func (m *MockRedisClient) LLen(arg0 context.Context, arg1 string) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "LLen", arg0, arg1)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// LLen indicates an expected call of LLen.
func (mr *MockRedisClientMockRecorder) LLen(arg0, arg1 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "LLen", reflect.TypeOf((*MockRedisClient)(nil).LLen), arg0, arg1)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// LPop mocks base method.
func (m *MockRedisClient) LPop(arg0 context.Context, arg1 string) *redis.StringCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "LPop", arg0, arg1)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
ret0, _ := ret[0].(*redis.StringCmd)
return ret0
}
// LPop indicates an expected call of LPop.
func (mr *MockRedisClientMockRecorder) LPop(arg0, arg1 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "LPop", reflect.TypeOf((*MockRedisClient)(nil).LPop), arg0, arg1)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// Ping mocks base method.
func (m *MockRedisClient) Ping(arg0 context.Context) *redis.StatusCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "Ping", arg0)
ret0, _ := ret[0].(*redis.StatusCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// Ping indicates an expected call of Ping.
func (mr *MockRedisClientMockRecorder) Ping(arg0 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Ping", reflect.TypeOf((*MockRedisClient)(nil).Ping), arg0)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// RPush mocks base method.
func (m *MockRedisClient) RPush(arg0 context.Context, arg1 string, arg2 ...any) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
varargs := []any{arg0, arg1}
for _, a := range arg2 {
varargs = append(varargs, a)
}
ret := m.ctrl.Call(m, "RPush", varargs...)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// RPush indicates an expected call of RPush.
func (mr *MockRedisClientMockRecorder) RPush(arg0, arg1 any, arg2 ...any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
varargs := append([]any{arg0, arg1}, arg2...)
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "RPush", reflect.TypeOf((*MockRedisClient)(nil).RPush), varargs...)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// SAdd mocks base method.
func (m *MockRedisClient) SAdd(arg0 context.Context, arg1 string, arg2 ...any) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
varargs := []any{arg0, arg1}
for _, a := range arg2 {
varargs = append(varargs, a)
}
ret := m.ctrl.Call(m, "SAdd", varargs...)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// SAdd indicates an expected call of SAdd.
func (mr *MockRedisClientMockRecorder) SAdd(arg0, arg1 any, arg2 ...any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
varargs := append([]any{arg0, arg1}, arg2...)
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "SAdd", reflect.TypeOf((*MockRedisClient)(nil).SAdd), varargs...)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// SIsMember mocks base method.
func (m *MockRedisClient) SIsMember(arg0 context.Context, arg1 string, arg2 any) *redis.BoolCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "SIsMember", arg0, arg1, arg2)
ret0, _ := ret[0].(*redis.BoolCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// SIsMember indicates an expected call of SIsMember.
func (mr *MockRedisClientMockRecorder) SIsMember(arg0, arg1, arg2 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "SIsMember", reflect.TypeOf((*MockRedisClient)(nil).SIsMember), arg0, arg1, arg2)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// SRem mocks base method.
func (m *MockRedisClient) SRem(arg0 context.Context, arg1 string, arg2 ...any) *redis.IntCmd {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
m.ctrl.T.Helper()
varargs := []any{arg0, arg1}
for _, a := range arg2 {
varargs = append(varargs, a)
}
ret := m.ctrl.Call(m, "SRem", varargs...)
ret0, _ := ret[0].(*redis.IntCmd)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
return ret0
}
// SRem indicates an expected call of SRem.
func (mr *MockRedisClientMockRecorder) SRem(arg0, arg1 any, arg2 ...any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
varargs := append([]any{arg0, arg1}, arg2...)
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "SRem", reflect.TypeOf((*MockRedisClient)(nil).SRem), varargs...)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}
// Set mocks base method.
func (m *MockRedisClient) Set(arg0 context.Context, arg1 string, arg2 any, arg3 time.Duration) *redis.StatusCmd {
m.ctrl.T.Helper()
ret := m.ctrl.Call(m, "Set", arg0, arg1, arg2, arg3)
ret0, _ := ret[0].(*redis.StatusCmd)
return ret0
}
// Set indicates an expected call of Set.
func (mr *MockRedisClientMockRecorder) Set(arg0, arg1, arg2, arg3 any) *gomock.Call {
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
mr.mock.ctrl.T.Helper()
return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Set", reflect.TypeOf((*MockRedisClient)(nil).Set), arg0, arg1, arg2, arg3)
refactor: redis queue backend test cleanup Summary: - Move existing test under a `testify` Suite as `baseRedisWithServerTestSuite` - Those tests require real redis server. - Add `go.uber.org/mock/mockgen@latest` as dependency - as a tool (Makefile). - in the `go.mod` file. - Mock redis client lives under a `mock` directory under the queue module. - That mock module has an extra hand-written mock in-memory redis-like struct. - Add tests using the mock redis client. - Changed the logic around queue provider creation. - Now the `getNewQueue` returns a Queue provider directly, not an init function to create it. The whole Queue module is close to impossible to test properly because everything is private, everything goes through a struct route. Because of that, we can't test for example what keys are used for given queue. To overcome this, as a first step I removed one step from that hard route by allowing custom calls to create new queue provider. To achieve this, I moved the creation logic into the `getNewQueue` (previously it was `getNewQueueFn`). That changes nothing on that side, everything goes as before, except the `newXXX` call happens directly in that function and not outside that. That made it possible to add extra provider specific parameters to those function (`newXXX`). For example a client on redis. Calling it through the `getNewQueue` function, it gets `nil`. - If the provided client is not `nil`, it will use that instead of the connection string. - If it's `nil` (default behaviour), it creates a new redis client as it did before, no changes to that. The rest of the provider code is unchanged. All these changes were required to make it possible to generate mock clients for providers and use them. For the tests, the existing two test cases are good with redis server, and they need some extra helpers, for example to start a new redis server if required, or waiting on a redis server to be ready to use. These helpers are only required for test cases using real redis server. For better isolation, moved existing test under a testify Suite, and moved them into a new test file called `base_redis_with_server_test.go` because, well they test the code with server. These tests do exactly the same as before, calling the same sub-tests the same way as before, the only change is the structure of the test (remove repetition, scope server related helper functions). Finally, we can create unit tests without redis server. The main focus of this group of tests are higher level overview of operations. With the mock redis client we can set up expectations about used queue names, received values, return value to simulate faulty state. These new unit test functions don't test all functionality, at least it's not aimed for it now. It's more about the possibility of doing that and add extra tests around parts we couldn't test before, for example key. What extra features can test the new unit test group: - What is the received key for given queue? For example using `prefix`, or if all the `SXxx` calls are expected to use `queue_unique` if it's a unique queue. - If it's not a unique queue, no `SXxx` functions are called, because those sets are used only to check if a value is unique or not. - `HasItem` return `false` always if it's a non-unique queue. - All functions are called exactly `N` times, and we don't have any unexpected calls to redis from the code. Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
2024-05-20 12:13:42 -05:00
}