# Test your integration

Test the adapter at the public interface it uses. A mocked successful response can check decoding, but a real server check is needed to verify authentication, database selection, session behavior and rejected requests together.

## Cover the application contract

Include a successful read, an empty result, a nullable field and an invalid SQL statement. Exercise representative integer limits and text containing quotes, delimiters and newlines through the chosen [format](https://coordinatordb.com/docs/reference/formats). Check invalid credentials separately from invalid SQL so callers receive the correct failure category.

For writes, verify committed rows by reading them back. Check rollback and a connection ending before commit. HTTP transactions must complete inside one request, while a native transaction belongs to its connection; see [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions).

## Exercise limits and cleanup

Test the application's handling of a truncated result, a rejected request and a network failure. For HTTP, preserve relevant headers such as `X-Coordinator-Query-Id` and `X-Coordinator-Result-Truncated` in diagnostics without logging credentials.

Use isolated data and stop only the server started by the test. Record executable versions and configuration with results. Include a file-input test when the adapter promises imports. The [automated checks guide](https://coordinatordb.com/docs/resources/develop-contribute/contribute/continuous-integration) explains readiness and independent test environments.