Skip to main content
The SDK uses native Fetch and returns a structured result by default. Test the client boundary you own: configure createKomgaClient, inject a Fetch implementation, and assert the generated operation receives the expected response.

Integration testing

Use a dedicated Komga instance and credentials for end-to-end tests. Keep the server URL and credentials in environment variables rather than committing them:
This exercises authentication, request serialization, and the server response. Use API-key authentication instead when that is how the deployment is configured. Keep integration data in a disposable library: write operations can change server state.

Test a custom Fetch implementation

A custom Fetch function has the platform fetch(input, init) signature. Record a real Request and return a native Response; do not return parsed JSON or a custom response object:

Assert serialized DTOs and headers

For a body operation, inspect the request after the generated client has serialized the named DTO. A 204 response models the operation’s no-content success:

Test structured failures

Generated calls do not throw for HTTP errors unless you use unwrap. Return an error response from the injected Fetch implementation to test the non-throwing result:
When the application prefers exceptions, call unwrap(result) and assert KomgaApiError separately:
Network errors can produce a result without response; test those separately if the application needs to distinguish transport failures from HTTP errors.

Run repository tests

Run the type checker as part of CI:

Next steps