{
  "id": 15554537,
  "title": "Turning a Broken Test Suite into a Deploy Gate",
  "url": "https://urgent.news/2026/10/19/turning-a-broken-test-suite-into-a-deploy-gate",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-19T04:02:39.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/sp0033212000/turning-a-broken-test-suite-into-a-deploy-gate-59no"
  },
  "original_language": "en",
  "account": "In September, the author ran yarn test on a NestJS API project, and discovered that 71 out of 87 test suites had failed. Nobody had noticed the failures, as no tests were run in the existing pipeline. By the end of the month, the test suite was green, with a runtime of 95 seconds, and a failing test now prevented a deploy.\n\nThe project consisted of a NestJS backend on Cloud Run, built by Cloud Build. The test suite contained 218 tests in 87 suites, with 90 of them failing consistently. The failures were due to Nest not being able to resolve dependencies of the RentalService, including PrismaService, GoogleService, FormatHelperService, GoogleMapService, and UserService.\n\nThe author identified that 69 of the failing tests were generated automatically by the Nest CLI, creating specs with a single it() test inside a testing module that provided the service, but none of its dependencies. These tests would always fail because the service had constructor arguments. The other 2 failing tests were real tests that had become outdated. After assessing the situation, the author decided to focus on fixing the real tests first, while keeping the unhelpful stubs for essential modules.\n\nAfter fixing the 21 real tests, the author deleted the remaining 62 stubs, as they provided no useful information and were causing maintenance issues. The test suite then passed 25 out of 87 suites, with 155 tests passing and one test being skipped. The overall runtime was reduced to 95 seconds.\n\nTo improve the workflow, the author added a pre-build step in Cloud Build that ran yarn install --frozen-lockfile && yarn test --ci --maxWorkers=2. This ensured that any failing tests would prevent a deploy, while also running the tests in GitHub Actions for better visibility and integration with the rest of the development pipeline.",
  "summary": "In September I ran yarn test on our NestJS API and 71 of 87 suites failed. Nobody had noticed, because nothing ran the tests. By the end of the month the suite was green, it ran in 95 seconds instead of 335, and a failing test stopped a deploy. Below is what I did, roughly in order, including a couple of things I chose to leave alone. How it got that bad Some context: I'm the only engineer at a…",
  "key_points": [
    "71 out of 87 test suites failed in NestJS API project",
    "21 real tests fixed, 62 stubs deleted to improve maintainability",
    "Pre-build step added to Cloud Build to prevent deploy on failing tests"
  ],
  "editors_take": "Integrating automated testing into the deployment pipeline transforms a neglected codebase into a reliable system where broken code can no longer reach production environments.",
  "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."
}