Open shaunco opened 1 year ago
Hello!
I see the point and agree that currently centrifuge-go
is not simple to use in unit tests... At the same time Client and Subscription are not interfaces because we need a way to extend them with methods without worrying about breaking compatibility.
Probably now it's much simpler to test with real Centrifuge server, running https://github.com/centrifugal/centrifuge Node with some handler.
But mocking is harder - I do not have clear answer now, looks like the best you can do is use dependency injection techniques in your code where you are depending on centrifuge-go
(I mean define interfaces in the place where you are using them). So you can granularly mock necessary parts.
Thanks @FZambia ! For now I built my own internal interface wrappers around Client
and Subscription
so that I can have one that just passes calls through to centrifuge-go and second generated by Mockery that can be used for unit testing.
As the centrifuge-go package stabilizes towards a v1, this would still be nice to have.
Client
andSubscription
(and probably others I missed) being exposed from the centrifuge-go library as astruct
makes it extremely difficult to mock them in unit tests. It would be nice ifClient
andSubscription
were aninterface
instead ofstruct
.