Download the PHP package uru/testhub-bundle without Composer

TestHub Bundle

Routes your application's outgoing HttpClient traffic to a TestHub sandbox, switchable per browser from the Symfony web profiler. Dev only.

Installation

Register the bundle for dev only in config/bundles.php:

Set the sandbox in .env.local:

The bundle also checks the kernel environment: in any environment not listed in test_hub.environments (default ['dev']) it registers nothing, even if it is enabled in bundles.php.

Usage

1. Open any page and click Test Hub in the debug toolbar (or use its Turn on link).
2. In the panel, set Use sandbox to On. The choice is saved in the testhub_sandbox cookie for this browser.

3. Reload your page. Provider requests made through http_client, including scoped clients, now go to the sandbox:

   • requests with a type (see Request type) and an agent go to {SANDBOX_URL}/api/{agent}/{type}/{event}
   • any other request, such as auth or calls to internal services, goes to the real API unchanged

   The original URL is sent in the sandbox-url header, the event in the sandbox-event header and SANDBOX_API_KEY in the sandbox-api-key header. The API key is sent only to the sandbox, never to real APIs, and is left out when it is empty.

4. The panel lists each outgoing request: original URL, sandbox URL, type/event, status, timing, request options, response headers and the sandbox response body.

Deposit event and Withdrawal event select whether the sandbox answers success or fail.

Request type

The type in the sandbox URL is resolved in this order:

1. extra.sandboxRequestType on the request, for non-standard types:

2. The request context's getDirection(), then getOperation(), when the value is deposit, withdraw or withdrawal. Deposits and withdrawals need no tagging.
3. Otherwise the request is not sent to the sandbox.

The Deposit event and Withdrawal event selectors apply to deposit and to withdraw/withdrawal. Every other type gets success.

The key goes directly under extra, which HttpClient ignores, so this code also runs in prod, where the bundle is not loaded. Use the string 'sandboxRequestType' if the class is not autoloaded in prod, for example because you installed the bundle with --dev.

The legacy location extra.curl.sandboxRequestType still works in dev, but in any environment without the bundle it makes cURL throw a TypeError. Move it to extra.

Console commands and workers have no browser cookie, so they use use_sandbox.

Agent context

The {agent} path segment comes from a context provider service. Its get() returns the contexts collected so far, one per outgoing request. The bundle uses the last one, which belongs to the request being sent, and calls its getAgent(). If the list is empty or the agent is null or empty, the request is not sent to the sandbox.

A request that collects no context of its own, for example an auth call made after a deposit, would still see the previous request's context. If the context has a getUrl() method, the bundle uses the context only when its host matches the request's host, so such calls go to the real API. Contexts without getUrl() are always used.

Implement the interface in your application. With autoconfiguration on (the Symfony default), the bundle finds your implementation and uses it instead of its empty DefaultContextProvider. You don't need any configuration:

The implementation is chosen in this order:

1. test_hub.context_provider, if set
2. your own alias for ContextProviderInterface in services.yaml
3. your only autoconfigured implementation. If there are several, the container fails to build and asks you to pick one with option 1.
4. DefaultContextProvider, which returns no agent

A provider with its own interface

If the bundle is installed with --dev, an application class that must also load in prod cannot implement TestHub\Bundle\...\ContextProviderInterface. Keep your own interface and point the bundle at the service. Any service with a public get(): array method works:

The context must be collected before the sandbox decorator runs. The decorator sits on http_client.transport with priority 100, so a collecting decorator with a lower decoration_priority (for example -20) runs first.

The Test Hub panel shows which provider is in use under Configuration. The provider is only built when a request is actually sent to the sandbox, so it can depend on services that use http_client themselves.

Actions

Actions are buttons in the Test Hub panel that run application code, for example processing a test payout that is waiting for the payout cron. Each run is a new request from your browser, so the Use sandbox and event controls apply, and the panel links to the run's profile with its HTTP calls.

Import the bundle routes for dev:

Implement ActionInterface. With autoconfiguration on, the action appears in the panel:

run() gets the submitted fields as trimmed strings. Its return value is shown in the panel; an exception is shown as a failure. Anything the action prints is captured and shown too. The panel remembers the last values in this browser.

Configuration

Until sandbox_url is set, the sandbox stays off, whatever the switch says.

If the sandbox uses a self-signed or private-CA certificate, point sandbox_cafile at its CA bundle, or set sandbox_verify_peer: false to skip the certificate and host name checks. Both apply only to requests sent to the sandbox. Requests to real APIs, including ones the sandbox passes through unchanged, keep the normal certificate checks.

Testing