-
Notifications
You must be signed in to change notification settings - Fork 94
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
Best approach for mocking container services #61
Comments
You're very welcome. Thank you for the compliment. I'm glad to hear you're finding it useful. Great question (and I agree, having something explicit about this in the README is a good idea). What I'd recommend is similar to what was done for the database. Add this new service to the container as an interface and when initializing it in To the best of my knowledge, there isn't an official way to determine if you're running within a test, so manually setting this environment is still required. Let me know if that works for you. |
That worked! However, I slightly dislike the following:
I was thinking about perhaps extending the DI approach to creating the service container itself, to enable swapping its own dependencies: the service clients. For example, allowing Any thoughts on the current opaque container vs one that acknowledges its dependencies (or at least some of them) and allows them to be (optionally) passed as parameters? |
You bring up good points. Similar to what you suggested, what do you think about either of these?
|
I tried option 1, and it seems to work. Here is what I tried:
Comments:
About option 2: I share your dislike to option 2, since it unnecessarily creates the non-test clients then overwrites them. About option 3: I think option 3 is a variation of option 1, in which |
Keeping |
Sorry for the delay. I was unavailable the last week. As you pointed out, you can't share code in test files across packages. I've ran in to that many times and it's a bit annoying, but understandable. You'll face the same issues no matter what your DI approach is. The container is really just a wrapper around multiple dependencies and makes it a bit easier to pass things around (.. I think). I personally don't worry about having mock clients reside outside of test code. If I write a package with a given service (ie, Without seeing the rest of your project, it's hard to evaluate your options and give any more guidance. It sounds like you're on the right path though. |
Thank you @mikestefanello for this joyful template. It got me excited about building web applications in Go.
I have a custom service that I added to the container, that calls an external service (REST API). Any suggestions or recommendations for ways to test the application without making those REST API calls?
It would be great to say something about that in the README.
The text was updated successfully, but these errors were encountered: