Make an HTTP fake verify the request you intended to send

An integration test uses a fake supplier response and passes, even after a refactor removes the authorization header. The fake made the response convenient but did not verify the outgoing request contract.

Assert method, URL, and relevant data

use Illuminate\Support\Facades\Http;

Http::preventStrayRequests();
Http::fake(['supplier.test/api/stock' => Http::response(['stock' => 0], 200)]);
Http::withToken('test-token')->get('https://supplier.test/api/stock', ['sku' => 'AX-1']);
Http::assertSent(fn ($request) =>
    $request->method() === 'GET'
    && $request->hasHeader('Authorization', 'Bearer test-token')
    && $request['sku'] === 'AX-1'
);

Use a clearly fictional host and token in tests. Preventing stray requests catches unexpected URLs instead of letting a test contact a real service. Match the actual endpoint pattern your client uses, including query handling where relevant.

A fake is not a live integration check

The response fixture reflects assumptions you wrote. Compare it with the provider's current contract and keep separate evidence for any real sandbox or production verification. Do not describe a passing fake as proof that credentials, network access, or rate limits work live.

Add cases for a zero stock value, a missing field, malformed JSON, an error response, and a connection failure. Assert what happens to previously stored stock after each failure. That is usually more valuable than checking that the helper returned an array. The integration boundary should preserve good data when the provider response is unusable.

Reference

Official documentation.