Recently I came across tests that require mocking server responses.
In general I am talking about tests that expect an API call during some action, and want to control (and later assert) the response that comes from the server.
From a quick look in the internet, I can see two directions to add such a capability to tests:
I’m torn. Maintaining explicit mocks/stubs for an API is a pain, but storing tons of huge VCRs is also noisy. My preference is still to use integration tests where possible.
In this particular scenario there is a tight client and server integration so I’d suggest system tests (which in our code are often still called integration tests) to really test the flow end-to-end.
I’m wondering if we can do something that will automatically update the api snapshot files, for example before every tests run (all the tests, not before each single test). So we can combine the big foreman set up (like in capybara), but only do it once before the tests
Being able to (re)record API snapshots is something I certainly expect from any VCR-like library. It looks like nock (as used by Katello) can do this (GitHub - nock/nock: HTTP server mocking and expectations library for Node.js) so I could see some scripting (rake task?) that sets up the Foreman test server in a certain state for the fixtures to be recorded. I’d hope the building up the state heavily relies on the factories in Foreman.
We can then decide if we want to store these in git (which to implies some CI that also verifies the fixtures are up to date) or depend on the invoker (either CI or a developer) to run the recording task.
As a closing note I’d like to emphasize that I do see value in testing at multiple levels of integration. It can be faster to have a limited scope, but you can also miss the big picture bugs that only show up in combinations.
