Read the code.
Find the risks worth testing.

1. Copy the source and its context

Training requirements: quantity must be an integer from 1–10; price comes from the server’s menu; one checkout attempt must create at most one charge and order; a failed dependency must not be reported as success.

// checkout.js — fictional server-side teaching sample.
// Analyze only. Do not deploy or run this deliberately flawed example.
// Injected interfaces: paymentClient.charge(), orders.insert(), email.send().

export async function checkout(request, { paymentClient, orders, email }) {
  const { drink, quantity, unitPrice, customerEmail, attemptId } = request.body;
  const total = quantity * unitPrice;

  let payment;
  try {
    payment = await paymentClient.charge({
      amount: total, currency: 'USD', email: customerEmail
    });
  } catch (error) {
    // Retry after any failure; the first attempt may already have charged.
    payment = await paymentClient.charge({
      amount: total, currency: 'USD', email: customerEmail
    });
  }

  const order = await orders.insert({
    drink, quantity, total, paymentId: payment.id, attemptId
  });
  // A confirmation-email outage fails the request after payment and insertion.
  await email.send(customerEmail, 'Your coffee is ordered', order.id);
  return { status: 200, orderId: order.id, total };
}

// package.json excerpt — no lockfile supplied with this exercise.
{
  "type": "module",
  "dependencies": {
    "express": "*",
    "axios": "latest"
  }
}

// Context: a browser can submit or repeat the checkout request.
// Payment, database, and email are separate services, with no shared transaction.
// Provider retry, timeout, and idempotency guarantees have not been supplied.
// Authentication middleware, schema constraints, and runtime configuration
// are outside this excerpt. Do not assume they are absent system-wide.

This is a combined review artifact, not a runnable JavaScript file. It intentionally includes code and a package.json excerpt.

2. Ask for a prioritized risk analysis

Analyze the supplied TestBucks checkout source and dependency context for testing risks. Work read-only: do not execute, install dependencies, call services, or modify code.

Focus on missing input validation, server-owned pricing, retry safety, duplicate charges or orders, timeouts, partial failures, and risky dependencies. Trace the path across payment, order storage, and confirmation email. Compare the implementation with these requirements: quantity is an integer from 1–10; pricing comes from the server menu; one checkout attempt produces at most one charge and order; dependency failure must not be falsely reported as success.

Return a stack-ranked table containing: risk, user/business impact, exact code evidence, what is known versus assumed, and the highest-value test to investigate it. For each proposed test, include setup, fault or input, and expected outcome. Distinguish risks demonstrated by this excerpt from controls that may exist elsewhere. Ask for missing middleware, database constraints, provider guarantees, timeouts, and configuration where they could change your judgment.

Review dependency version ranges and the missing lockfile. Do not claim a known vulnerability without checking the actual resolved version against an authoritative advisory. Lack of a lockfile in this sample does not prove the real project has none.

End with the top three tests to run first and the additional source or context you need. Do not call the application safe simply because the code looks plausible. Do not invent runtime test results.

For your own project, adapt the sample requirements to your actual product rules before asking the agent to review it.

3. Review the risks—not just the list length

Pick one risk and explain the test that would give you the most useful new evidence.