Hi @Santhosh17713 maybe you could write your own interface that only has on it the functions that you need from the gocb bucket (and matches the function signatures). That way you could add a ConnectCbRepository(repository CbRepositoryInterface) function or similar and when you setup the repositoryCb in your tests you can pass ConnectCbRepository a mocked version instead of an actual cbRepository. Would something like that work?
Thanks @chvck for your suggestion. Yes, I did try that. But the problem is the couchbase crud instructions like insert/upsert etc are having a receiver with type *gocb.Bucket. I am not sure, how to mock this.
@Santhosh17713 I see what you mean. If you were to change the types on CbRepository so that it looked more like
type CbRepository struct {
Cluster Cluster
Bucket Bucket
}
Where Cluster and Bucket are your own interfaces where Bucket looked something like (but with all the function calls that you use)
type Bucket interface {
Insert(key string, value interface{}, expiry uint32) (gocb.Cas, error)
Upsert(key string, value interface{}, expiry uint32) (gocb.Cas, error)
}
then in your tests rather than calling NewCbRepository() to create the CbRepository you could just inject your mocked Cluster and Bucket objects via &CbRepository{Cluster:&myMockCluster{}, Bucket:&myMockBucket{}}. This is somewhat dependant on how your tests work and how you inject the repository into the service layer but if you did that then you’d be mocking gocb out in such a way that the receiver type on the calls wouldn’t matter because CbRepository wouldn’t even know if the Bucket belonged to gocb.