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. 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.

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 explains readiness and independent test environments.