Integration testing in Base

Unit and module tests prove each piece works. Integration tests prove the pieces work together: that a request actually routes to the right handler, that the decorators actually bind the arguments, that serialization actually round-trips, that the whole worker, stood up and talking, behaves. This is the truest test Base offers, and the example worker leans on it heavily.

Stand up the worker, then use it

An integration test in Base does not poke at internals. It stands up the worker and talks to it the way a real client would. You reach for the test environment, get a client off it, and send real operations: an HTTP request to a route, a GraphQL query, an RPC call. Then you assert on what comes back, the status, the body, the shape of the result, exactly as a consumer of your worker would receive it.

That is what makes these tests trustworthy. There is no mock of the framework in the middle. The request goes through the same routing, the same decorators, the same serialization that a production request goes through. When an integration test passes, the path it exercised is a real path, proven end to end.

What a real one looks like

The example worker's integration tests are the model to copy. A router test gets the base URL from the test environment's client, sends a request to a route, reads the response, and asserts on the status and body. A test for a path parameter sends a request with the parameter filled in and asserts the handler received it correctly. A query-parameter test sends the query string and checks the parsed result. Each test is small, each exercises one route or one operation, and each reads like a few lines of a program that uses your worker.

The same shape covers the other surfaces. An RPC integration test calls a method through the client and asserts on the returned value. A GraphQL test runs an operation and asserts on the data. An ORM test exercises a repository against the real data layer. One environment, one client, many small tests, each hitting one real thing.

Where integration tests earn their cost

Integration tests are slower than unit tests, because standing up a worker and sending real traffic costs more than calling a function. So you do not write thousands of them. You write enough to cover the wiring: the routes that matter, the operations a client depends on, the paths where the pieces meeting is where the risk lives. The decorators binding arguments, the serialization preserving a shape across the wire, the auth middleware actually blocking, these are integration concerns, and an integration test is the only test that can honestly check them.

The balance to aim for is many fast unit and module tests underneath, and a deliberate layer of integration tests over the surface a client actually uses. The fast tests find logic bugs in milliseconds; the integration tests find wiring bugs that no isolated test could see.

The mental model to keep

Integration testing in Base means standing up the worker and exercising its real surface through the test client: send HTTP, GraphQL, and RPC against routes and operations that go through the same routing, decorators, and serialization as production, then assert on what a real client would receive. Copy the example worker's tests as your model, keep each test small and focused on one operation, and write enough of them to cover the wiring without trying to replace your fast unit tests.