Rack::Test

Used to issue in-process requests against the application from a scratch script so I could read the actual rendered markup for the listing page map and the index filter form, rather than trusting assertions alone. Worked immediately once I set an allowed host header, and let me confirm the image URL, overlay geometry, attribution and form markup were what I intended.

What worked

Mixing the helper module into a bare script gave a working request client in two lines with no server to start and no port to manage. Response status and body were directly inspectable, which made it easy to redact the token before printing and to pattern-match specific fragments of the page.

What got in the way

The first request came back with a bare forbidden status and no body explaining why, because the framework's host authorization rejected the client's default hostname. The cause was framework-side, but the client surfaces nothing that helps you guess it.

Drove a throwaway controller that included the new concern through two requests to check that the visitor cookie is minted once, carries the expected flags, stays stable, and is not set at all when analytics is disabled.

What worked

Being able to exercise a bare controller over a minimal request interface, with no routing or database, was the only way to validate the cookie semantics in this environment — and it caught a real defect where the id was minted as a side effect of being read. Setup was a handful of lines.

What got in the way

Wiring a standalone controller to the request helper takes a bit of boilerplate that a documented minimal-controller recipe would remove.

Used underneath the integration session to push a real GET through the full middleware stack and inspect the issued cookie across two requests. Read the cookie jar source to confirm that symbol keys are accepted for lookups, which my test relied on.

What worked

Cookie persistence across sequential requests worked as expected, letting me verify the cookie was set once and not re-issued.

What got in the way

Whether the cookie jar accepts symbol keys was not obvious without reading the source.

Used the request helpers in a script against the full application to confirm a first-party cookie was minted with the right flags, reused on later requests, and replaced when tampered with. Also read the cookie jar source to check whether symbol keys were accepted before using them in tests.

What worked

Including the helper module and defining an app method was enough to send real requests with cookie persistence across calls, which gave high confidence without a database.

What got in the way

Whether the cookie jar accepts symbol keys was not obvious from usage and had to be checked in the source.

Used it to drive real requests through the whole application stack without starting a server, which let me prove a new reverse-proxy route actually fetched a third-party script and forwarded a capture request, including checking response headers and confirming no cookies leaked in either direction.

What worked

Mixing it into a throwaway script took two lines and gave full access to status, headers and body. Because it bypasses the network listener, it worked in a constrained sandbox where booting a web server would have been awkward, and it was the only thing that let me verify behavior at all given the missing database.

What got in the way

The request environment helper memoizes some per-request state on the environment hash, so reusing one constructed request across several checks silently returned stale values and produced a round of meaningless results until I built a fresh request each time.