The docs for the testing javascript talk about running the local test server. And that’s fine for e2e tests. But I don’t want to actually make backend requests for many tests, rather I want to mock backend responses.
I’ve made some progress using third party test frameworks, but part of the difficulty is that if my code uses features of the fastly runtime such as 'fastly:config-store", then I run into problems using e.g. node.
Are there examples of this sort of thing?
If I understand this properly, you want to test your Compute code in the local test server (Viceroy) and have the outbound requests that it makes go to a local HTTP server which will provide mocked responses?
If so, the JS testing framework could certainly be extended to offer something like that; the instance of Node that is being used to run the tests could also listen for incoming requests, and the local_servers section of the fastly.toml could define a backend which sends requests to that Node process.
Not quite - I want to be able to run the compute service logic without having to make real backend requests (rather mock those requests).
For now I have something working use vitest and this plugin GitHub - ysugimoto/vite-plugin-fastly-js-compute: Vite plugin for Fastly Compute
This allows me to mock the backend responses for the purpose of tests using vitest; the plugin ensures that I don’t need to use the fastly runtime (I can use node) without errors for the fastly:... specific functionality.
Interesting; the challenge there will be that if your Compute service code relies on data from a Config Store/KV Store/Secret Store/etc. in order to construct backend requests, you won’t be able to run that code the same way as you would normally.
I’m curious to learn how mocking the backend responses in the same process vs. mocking them in an external process would be functionally different (other than needing to manage the external process of course). Since the platform itself manipulates the content of responses before handing to them to Compute service code, I’d think it would be better to allow the normal platform behavior to occur ‘on top’ of the mocked response, rather than trying to emulate it.
Do you have a relatively simple example you can share of what you are doing in Node, and what would be different (or not possible) if that was done in Viceroy+Node?
Right, but I can also mock the data I get back from config store/KV/ whatever.
You’re probably right that the backend requests can be mocked in the external process. The problem I had was that the mocking libraries I experimented with were unhappy with any imports from fastly:... Quite possibly there’s a way round this. I’m not super experienced with javascript anyhow, I expect that there’s plenty that could be done in other ways.
I’ll make a simple example in due course.
Indeed, so you either have to mock the backend responses, or mock the backend responses and the platform responses 
Since Viceroy already knows how to do the second part, I’m thinking we could provide an easy way to provide a method for the first part.
If you’re using our js-compute-testing package already, that’s what I have in mind. The ‘test driver’ is running in Node, it would be easy enough to launch an Express server in that Node application and connect a ‘local backend’ from Viceroy to it. At that point you could write routes as you would in any web server and provide the mock responses that you want to deliver.
OK - here’s an example: GitHub - ismfg/fastly-compute-vitest-example.
Thanks! That’s roughly what I expected to see.
What I’m thinking about would be take the example here and import Hono into it as well, and provide the port number that Hono is listening on to app.start so that it could be fed over to Viceroy to be used as a local backend.
With that in place, some (or all) of the app.fetch invocations for test cases would result in the request going through Viceroy (and your Compute service code) and landing in Hono, where your routes would decide which response to provide.
@harmony7 What do you think about doing something like this?
Hi.
Yes, @kevin.fleming is right. The testing library is designed to start your Compute application and simplify making calls to it. What the Compute application uses as a backend is outside its scope. If you need to configure [local_server] inside your fastly.toml, for backends or data stores or whatever, for now you should do all that beforehand and then start your testing.
That said, if there are ways we can extend this tool, such as adding hooks to help configure backends and/or Viceroy, we’re open to ideas.