Audit advanced Works with: Any AI

Integration Test Coverage of External Dependencies

Table output Has example

Check tests around databases, APIs and queues.

The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.

Review integration tests. Dependencies the system uses (database, payment API, queue, email): [DEPENDENCIES]. Existing integration tests: [INTEGRATION_TESTS]. How test environments are provided: [TEST_ENVIRONMENTS].

For each dependency check coverage of success, failure, timeout, retry, malformed response and version change. Check whether tests use real services, containers or fakes, and whether fakes match the real contract. Identify risks from shared test data and test order.

Return a coverage matrix, recommendations for contract tests, and a plan for a small set of end-to-end checks that run before release. Do not include real credentials.

Add a worked coverage matrix with invented ratings. Database: success yes, failure partial (connection loss untested), timeout no, retry no, malformed data n/a, version change no. Payment API: success yes, failure yes (declined card), timeout no, retry no, malformed response no, version change no. Email service: success yes, failure no, timeout no. Message queue: success yes, duplicates no, ordering no. Count the cells covered: 6 of 22, about 27 percent, and rank the missing ones by impact: payment timeouts and retries could lead to double charges; queue duplicates could duplicate emails. Propose contract tests that check our assumptions about the payment API's responses against recorded examples, and fakes that can simulate delays and errors. Describe how to avoid shared state between tests by creating isolated data per test and cleaning up. Provide a small end-to-end smoke suite of five checks that run before every release: sign in, search, add to basket, pay with a test card, receive confirmation. Add notes on running third-party sandbox environments and respecting their limits, keeping API keys in the secret store and not in test files, and flagging tests that call live services. Include a plan for checking that timeouts and retries are idempotent: a retried payment request must not charge twice, and the test should prove it. Estimate the effort for each addition in hours and prioritise.

Fill in before use

Optional: type your details and the prompt above updates. Nothing is saved or sent.

Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.

Invented matrix of 22 cells across four dependencies and scenarios (success, failure, timeout, retry, malformed response, version change).
Covered: database success, part of failure; payment success and declined card; email success; queue success. Total 6 of 22 = 27 percent.
Highest risks missing: payment timeouts and retries (possible double charge); queue duplicates (duplicate emails).
Smoke suite before release: sign in, search, add to basket, pay with a test card, confirmation (5 checks).
Test the retry: the same payment request sent twice must charge once.

• audit