[feature request] Provide a way to mock backend responses when using viceroy as a test runner

[tedmielczarek-fastly]

When using viceroy as a test runner it would be helpful if there were a way to mock backend responses. The motivation for this is twofold:

1. Tests that make external network requests are inherently flaky due to transient network issues. It would be much better for reliability if backend requests in tests did not have to make an external request.
2. Writing unit-style tests is much easier if you can mock external dependencies. If your test is making external requests it's an integration test whether you like it or not. While integration tests are valuable, using mocks for unit tests allows writing tests for edge cases such as handling specific errors which are much more difficult to test against a real external service.

I don't know the viceroy codebase well so I can't offer useful implementation suggestions, but from a user's perspective I can imagine a few ideas of solutions that would be useful:

• A hostcall that allows mocking requests for a backend, either by providing a handler routine in the wasm module or by directly providing a response that should be used.
• A commandline argument to provide a handler routine in the wasm module to be used to handle requests for a specific backend, e.g. --mock-backend=my-backend=some_function_name.

Either of these would provide enough functionality to address the two points in the motivation list above.

[dgryski]

Depending on the level of configurability needed, we could even do something like embedding https://github.com/facebook/starlark-rust to allow viceroy "scripts" to handle creating responses.

[tedmielczarek-fastly]

For the purposes of mocking backends for tests I would personally prefer a solution that allows using a handler function alongside the existing code in the module.

[lewiscowper]

I have the same use case, and provide a chained with_response function on our request struct that is only compiled under #[cfg(test)] for unit tests purposes, and then I have a wrapped send function that, along with other things, checks whether the Option<Response> has a value, and if it does, it returns it instead of calling Request::send().

I'm not sure how viceroy support would look for that use-case, as I'm already one abstraction away from operating on "raw" fastly::Request objects. But an in-memory backend (or multiple for some cases) would probably move in the right direction.

For viceroy as a library in an integration test, I use httpmock, and create a struct that holds both the ExecuteCtx and an httpmock::MockServer. This allows me to call a mock function instead of making an origin call, and I can add conditions (with httpmock::When and httpmock::Then) so that I can test specific cases where the Compute service modifies a request before passing it on to the origin.

It's a different implementation to Stellate's work, but that was one of the inspirations.

Built in support in the ExecuteCtx for a Result type (ideally a function that could be called that returns a Result) would likely mean I would be able to deprecate the entire httpmock dependency for integration tests.