{
  "id": 5056267,
  "title": "Generating test cases is the easy part",
  "url": "https://urgent.news/2026/09/02/generating-test-cases-is-the-easy-part",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-02T09:07:50.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/2sdtechnologiesdotcom/generating-test-cases-is-the-easy-part-41e9"
  },
  "original_language": "en",
  "account": "Writing test cases is a straightforward task, but the true limit lies elsewhere. Generating test cases is easy, but ensuring their quality and relevance poses a challenge. The actual barrier is the time and effort required to thoroughly scrutinize each case.\n\nConsider this example: \"As a customer I can apply a promo code at checkout.\" A competent engineer can easily come up with three basic cases: a valid code accepted, an invalid code rejected, and an expired code rejected. These cases directly correspond to the requirements' stated conditions. However, there are numerous other scenarios worth testing that were not explicitly mentioned in the requirement.\n\nHere are six additional scenarios that could lead to defects: applying the same code twice in one basket, applying a code at the minimum basket value, combining the code with a gift card, using the code on a partially refunded order, applying the code in a different currency, and applying the code when it expires between the basket and payment. These scenarios are not explicitly stated in the requirement, but they are worth considering as potential defects.\n\nThere are distinct categories to consider when generating test cases: idempotency, boundary conditions, composition, prior state, locale, and time-of-check to time-of-use. These categories cover various aspects of the system and help in identifying potential issues that may not be explicitly mentioned in the requirement.\n\nTo generate test cases effectively, start with one acceptance criterion and use language models to enumerate the categories and their combinations with the feature. However, not all generated cases are equally valuable. A generated case must be traceable to a requirement or code branch, prioritized, survive maintenance, and fail loudly when uncertain.\n\nGeneration does not eliminate human judgment; instead, it shifts it from case writing to reviewing. This shift is beneficial as reviewing proposed cases against the requirement is faster than creating cases from scratch. The categories provide a structured approach to reviewing cases, making it easier to identify potential gaps.\n\nHowever, this approach requires capacity for review. Without capacity to review, generated tests may lead to a large suite with unexamined assumptions, resulting in a problem rather than a solution. Therefore, it is crucial to start with one acceptance criterion, generate test cases using the six categories, and assess the number of cases that align with your requirements. This number represents your coverage ceiling and is usually a realistic target.",
  "summary": "There is a ceiling on your test coverage and it is not technical. Running tests has been a solved problem for a long time. Runners are fast, parallelism is cheap, CI is a commodity. None of that touches the actual limit, which is that somebody has to sit down, read the requirement, work out what could go wrong, and write the cases. So coverage ends up being a function of how much of that a person…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}