André Arko discusses the often overlooked but crucial practice of deleting tests in software development. While conventional wisdom in methodologies like Agile, TDD, and BDD emphasizes adding tests to boost confidence in code changes, Arko argues that removing certain tests can be equally important for maintaining trust in a project’s integrity. He explains that automated tests exist primarily to provide developers and teams confidence that changes won’t break existing functionality. Running tests during development, continuous integration, and deployment ensures this confidence. However, tests that undermine confidence should be removed. Tests decrease confidence mainly when they are flaky—failing intermittently and unpredictably. Flaky tests waste engineers’ time, cause confusion, and can mask actual bugs. The cost of such tests, often measured in lost productivity over days or weeks, outweighs the uncertain benefit that a flaky test might someday catch an issue. Arko recommends deleting flaky tests immediately, replacing them only if and when a stable version can be written. Other reasons to delete tests include those that require excessive updates for minor code changes, massively bloating the testing workload without proportional confidence gains. Similarly, tests that take so long to run they are routinely skipped create false assurances and should be removed rather than ignored. Lastly, when business requirements evolve and existing tests validate outdated behavior, continuing to fix these tests is counterproductive. Instead, tests should focus on the new behavior, making the obsolete ones candidates for deletion. In sum, Arko urges a shift in mindset: tests are tools for confidence, not sacred artifacts. If a test reduces confidence—whether through flakiness, slow execution, excessive maintenance, or irrelevance—it should be deleted to keep the testing suite honest, effective, and manageable.