I imagine this is a fairly niche topic but I manage a Forem API client in .NET and currently I follow the bad idea of integration testing it against a live environment (dev.to) (without an API key of course, don't want people to spam articles under my account).
Why do I do integration tests for this? Well, I've found the API to be a little inconsistent with the documentation or between different API endpoints (yay API v0 BETA 🤣).
Besides unnecessary traffic going to the site (which would be extremely small but nonetheless, still traffic), there are limitations to what I can reasonably test as I can easily hit "Too Many Requests" when running my own CI.
My ideal situation would be to standup the bare minimum Forem instance I can during CI and testing against that instead. I have found documentation for setting up an instance on a local machine though that typically has different requirements than doing it via CI (for example, interactive prompts).
What may amount to a lot of actual help, I'd really like to get Forem instances being created for CI and data purged between tests with the least amount of infrastructure or configuration possible (because I'm not testing Forem, I'm testing my API client is actually correct to the current Forem code in GitHub).
Maybe this approach is just silly and I should approach this differently (eg. just mock the API and as long as I follow the documentation, I'll be fine) but at the same time, integration testing something like this feels like a good idea.
Would love to know your thoughts etc.
Top comments (1)
Having a staging environment for integration testing makes sense! I wonder if once the Forem Systems Stack is ready for the masses each developer could simply spin up their own throwaway staging environment for such tests:
A big day for Forem Systems
Joe Doss ・ Aug 10 '20 ・ 5 min read