You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The problem we are currently having is that we write mocks for interfaces ourselves which might be cumbersome and had to maintain especially for SDK.
Describe the feature you are requesting, as well as the possible use case(s) for it.
Instead of writing down each mock for individual interfaces use https://github.com/vektra/mockery or https://github.com/uber-go/mock to generate mocks for interfaces. This will be instrumental in testing. This is quite useful for services depending on the SDK for example, bootstrap and certs service. This approach simplifies the testing process as initially, one would need to generate the things services, then the things server and finally use the things server URL on the SDK. This effective means that when testing other services you inherently test services that depend on the SDK which is not ideal. With SDK mocks you can mock the SDK rather than mocking dependent services.
Due to the complexity of tests changes, we will update one service mock at a time. @nyagamunene@JeffMboya@arvindh123 Please comment here which services we need, and create issues out of that list. We must finish it by the end of S2.
Is your feature request related to a problem? Please describe.
The problem we are currently having is that we write mocks for interfaces ourselves which might be cumbersome and had to maintain especially for SDK.
Describe the feature you are requesting, as well as the possible use case(s) for it.
Instead of writing down each mock for individual interfaces use https://github.com/vektra/mockery or https://github.com/uber-go/mock to generate mocks for interfaces. This will be instrumental in testing. This is quite useful for services depending on the SDK for example, bootstrap and certs service. This approach simplifies the testing process as initially, one would need to generate the things services, then the things server and finally use the things server URL on the SDK. This effective means that when testing other services you inherently test services that depend on the SDK which is not ideal. With SDK mocks you can mock the SDK rather than mocking dependent services.
Indicate the importance of this feature to you.
Nice-to-have
Anything else?
Initial work is done at https://github.com/absmach/magistrala-old/pull/127
Procedure
auth
bootstrap https://github.com/absmach/magistrala/issues/2136
http - https://github.com/absmach/magistrala/issues/2170
invitations - https://github.com/absmach/magistrala/issues/2143
mqtt - https://github.com/absmach/magistrala/issues/2161
pkg
provision
things
users - https://github.com/absmach/magistrala/issues/2164
certs - https://github.com/absmach/magistrala/issues/2137
consumers - https://github.com/absmach/magistrala/issues/2147
lora - https://github.com/absmach/magistrala/issues/2145
readers - https://github.com/absmach/magistrala/issues/2166
twins - https://github.com/absmach/magistrala/issues/2173
Service/modules which have no mocks before
The text was updated successfully, but these errors were encountered: