Start with one request and one expected result
Your application sends a prompt through an SDK and displays the answer. Before connecting a live account, you can test that path with a mocked response: a prepared reply that stands in for an API response.
The goal is not to test whether a model gives a good answer. It is to check whether your application builds the right request, reads the response correctly, and handles failures without breaking the user experience.
Start with one small behavior: when someone submits a prompt, your application displays the returned text. Write down the expected result before building the test. For example, a prepared response containing “Your draft is ready” should produce exactly that text in the application.
Put the mock where the SDK sends HTTP requests
A useful integration test keeps the real SDK in place and replaces its network connection. Use an HTTP mocking library, a custom transport supported by your SDK, or a local test server. Your SDK still builds requests and parses responses, but no request reaches the live provider.
This is different from replacing your own application function with a function that always returns text. That simpler test can check display logic, but it skips the SDK’s request formatting and response parsing.
Keep the test isolated: use a dummy API key, block unexpected network requests, and make unmatched requests fail. Otherwise, a misspelled URL could accidentally send the test to a real service.
Build a fixture your SDK can actually read
A fixture is saved example data used by a test. For a non-streaming OpenAI-compatible chat completion, prepare an HTTP success response with a JSON body containing the fields your SDK expects. These commonly include an identifier, object type, creation timestamp, model, and a choices list containing an assistant message.
Start from the documented response format for the exact endpoint you use. Chat Completions and Responses are different interfaces; a fixture for one should not be assumed to work with the other. Include the appropriate content-type header, too.
Use a short, fixed answer in the fixture. Keep optional details minimal unless your application reads them. If you display token usage, include usage fields and check that your application reads them correctly.
Check the outgoing request before accepting the answer
A test that only checks the displayed answer can miss a broken configuration. Have your mock inspect the outgoing request before returning the fixture.
- Check the HTTP method and endpoint path.
- Check that the authorization header uses the dummy credential.
- Check that the request body contains the expected prompt and configured model identifier.
- Check any options your application depends on, such as whether streaming is disabled.
If you plan to use SwiftRelay with an OpenAI-compatible SDK, configure its base URL as https://api.fastapirelay.com/v1. Check the final request path so that /v1 is neither missing nor duplicated. Mocking this configuration lets you catch URL mistakes before spending tokens.
Rehearse failures your users might encounter
Once the successful path passes, add a few focused failure cases. Return an authentication error and confirm that your application offers a useful configuration message without exposing credentials. Return a rate-limit response and check that retries are bounded rather than endless.
Also test a connection failure and a response with no usable answer text. These reveal whether your application clears its loading state and gives the user a sensible next step. If the SDK retries automatically, configure that behavior explicitly so your test can predict how many requests occur.
For streaming, create separate tests using the endpoint’s actual event format, including completion and interruption behavior. A regular JSON fixture does not validate streaming.
Finish with a small live smoke test
Mocks prove that your integration handles the situations you prepared. They cannot confirm that a real credential works, a model is available, or the live service accepts your request.
When the mocked tests pass, sign up for SwiftRelay and use its small gift credit for a minimal live smoke test. Keep real credentials outside fixtures and source control. Then retain the mocked suite for routine checks, with live testing kept separate and deliberate.