Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client and Subscription types should be an interface to allow for mocking #86

Open
shaunco opened this issue Sep 11, 2023 · 2 comments
Open

Comments

@shaunco
Copy link

shaunco commented Sep 11, 2023

Client and Subscription (and probably others I missed) being exposed from the centrifuge-go library as a struct makes it extremely difficult to mock them in unit tests. It would be nice if Client and Subscription were an interface instead of struct.

@shaunco shaunco changed the title Client type should be an interface to allow for mocking Client and Subscription types should be an interface to allow for mocking Sep 11, 2023
@FZambia
Copy link
Member

FZambia commented Sep 11, 2023

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.

@shaunco
Copy link
Author

shaunco commented Sep 11, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants