chore: integration tests setup

[fforbeck]

Integration Test Setup for Cloudflare Local Worker

In this PR, I have implemented an integration test setup to verify the functionality of our Cloudflare Worker. This setup involves running the worker locally with all the bindings enabled in wrangler.toml (integration environment), and performing a series of HTTP requests to ensure the worker behaves as expected under various conditions.

By running the worker locally, we avoid the complexities and overhead associated with handling authentication for deploying a remote worker via CI. This makes the testing process more straightforward.

Key Components

1. Worker Fixture:

   • Purpose: The fixture file contains the setup and teardown logic for the Cloudflare Worker used in our tests.
   • Functions:
     • setupWorker: Deploys the worker and starts the local Wrangler dev server.
     • teardownWorker: Stops the local Wrangler dev server.
     • getWorkerState: Provides the current state of the worker, including IP, port, and output.

2. Integration Test Folder:

   • Purpose: This folder will contain the actual test files with logic to verify the worker's various functionalities.

Configuration

• Worker Configuration: The worker configuration is defined in the wrangler.toml file. This includes settings such as rate limiting, environment variables, and other configurations necessary for the worker to function correctly. Make sure you are editing the integration environment config - which is the default environment used by the integration test setup.

[Peeja]

[Peeja]

suggestion Maybe let's put these all in one object (the return value of await runWranglerDev()), to make it clear that they all get set together. I had to read through the whole file a couple of times to understand what was setting these.

Along those lines, let's separate the requested port (which is a constant) from the actual port, and stop providing default values for ip and port. Right now, they're lying until Wrangler boots. If Wrangler's not up yet, we should signal that rather than provide fake values.

One way to set this up (which might be overkill) would be to have mochaGlobalSetup() store the promise from runWranglerDev() rather than await it itself, and have getWorkerInfo() be async. Then the tests will start booting Wrangler and not wait for it to be set up until the values are actually requested. (We don't really have a performance issue here, though, so the choice should be down to which one communicates what's happening the clearest.)

[Peeja]

suggestion: Let's avoid all these lets and put the stuff below inside the new Promise(). It'll have access to resolve and reject, and we don't need to track settledReadyPromise at all: resolveing or rejecting after it's settled is a noop.

[travis]

praise: I like this move!

Most of the suggestions were implemented. The open ones won't be addressed for now.