TDD-Bench Verified: Can LLMs Generate Tests for Issues Before They Get Resolved?

TL;DR

TDD-Bench-Verified introduces a high-quality benchmark for generating tests from issue descriptions before code changes, filtering real-world SWE issues to 449 instances and evaluating test adequacy via a containerized harness that computes $tddScore$, which multiplies a correctness component (fail-to-pass) by a coverage-based adequacy component. It also presents Auto-TDD, a neuro-symbolic, few-shot pipeline that localizes a test file, extracts issue-related functions, and inserts a test function, achieving higher fail-to-pass rates than prior work and competitive coverage. Across zero-shot baselines and Auto-TDD, the study demonstrates meaningful improvements over prior approaches, with GPT-4o often delivering the strongest results, and highlights the critical role of test-file localization and function-recovery steps. The work advances practical automated test generation for TDD, offering a realistic benchmark and a scalable method that can inform developer productivity and robustness of issue-resolution-by-tests workflows.

Abstract

Test-driven development (TDD) is the practice of writing tests first and coding later, and the proponents of TDD expound its numerous benefits. For instance, given an issue on a source code repository, tests can clarify the desired behavior among stake-holders before anyone writes code for the agreed-upon fix. Although there has been a lot of work on automated test generation for the practice "write code first, test later", there has been little such automation for TDD. Ideally, tests for TDD should be fail-to-pass (i.e., fail before the issue is resolved and pass after) and have good adequacy with respect to covering the code changed during issue resolution. This paper introduces TDD-Bench Verified, a high-quality benchmark suite of 449 issues mined from real-world GitHub code repositories. The benchmark's evaluation harness runs only relevant tests in isolation for simple yet accurate coverage measurements, and the benchmark's dataset is filtered both by human judges and by execution in the harness. This paper also presents Auto-TDD, an LLM-based solution that takes as input an issue description and a codebase (prior to issue resolution) and returns as output a test that can be used to validate the changes made for resolving the issue. Our evaluation shows that Auto-TDD yields a better fail-to-pass rate than the strongest prior work while also yielding high coverage adequacy. Overall, we hope that this work helps make developers more productive at resolving issues while simultaneously leading to more robust fixes.

Figures (7)

• Figure 1: Overall flow of TDD-bench dataset filtering starting from SWE-bench verified
• Figure 2: Evaluation harness for TDD-Bench-Verified.
• Figure 3: Example test patch with one contributed test. Although the test file name test_regression.py and test name test_missing_data are available in this text, the class TestPolyFit enclosing test_missing_data is missing. By applying the test patch to the base commit and parsing the file, we retrieve TestPolyFit, which is required to run test_missing_data.
• Figure 4: Different prompts used in our approach: shows the prompt for the baseline zero-shot test file generation; --show the prompts used for the sequence of LLM calls (for selecting a test file, identifying issue-related test functions, and generating test functions) in Auto-TDD.
• Figure 5: Overall architecture of Auto-TDD.