Learning to Generate Unit Tests for Automated Debugging
Authors: Archiki Prasad
Elias Stengel-Eskin
Justin Chen
Zaid Khan
Mohit Bansal
Venue: COLM 2025 (2025)
Keywords: Unit Tests Generation
LLMs for code generation
LLMs for code debugging
TL;DR: LLM training pipeline for generating unit tests for code debugging and assessing code correctness

Abstract: Unit tests (UTs) play an instrumental role in assessing code correctness as well as providing feedback to large language models (LLMs), motivating automated test generation. However, we uncover a trade-off between generating unit test inputs that reveal errors when given a faulty code and correctly predicting the unit test output without access to the gold solution. To address this trade-off, we propose UTGen, which teaches LLMs to generate unit test inputs that reveal errors along with their correct expected outputs based on task descriptions. Since model-generated tests can provide noisy signals (e.g., from incorrectly predicted outputs), we propose UTDebug that (i) scales UTGen via test-time compute to improve UT output prediction, and (ii) validates and backtracks edits based on multiple generated UTs to avoid overfitting, and helps LLMs debug effectively. We show that UTGen outperforms other LLM-based baselines by 7.59% based on a metric measuring the presence of both error-revealing UT inputs and correct UT outputs. When used with UTDebug, we find that feedback from UTGen's unit tests improves pass@1 accuracy of Qwen2.5 32B on HumanEvalFix and our own harder debugging split of MBPP+ by over 3.17% and 12.35% (respectively) over other LLM-based UT generation baselines. Moreover, we observe that feedback from Qwen2.5 32B-based UTGen model can enhance debugging with frontier LLMs like GPT-4o by 13.8%. Lastly, we demonstrate that UTGen is a better judge for code correctness, outperforming a state-of-the-art trained 8B reward model by 4.43% on HumanEval+ with best-of-10 sampling using Qwen2.5 7B.

Published as a conference paper at COLM 2025
Learning to Generate Unit Tests for Automated Debugging
Archiki Prasad Zaid Khan
Elias Stengel-Eskin Mohit Bansal
Justin Chih-Yao Chen
University of North Carolina at Chapel Hill farchiki, esteng, cychen, zaidkhan, mbansal] enc.edu
Abstract
Unit tests (UTs) play an instrumental role in assessing code correctness as well as providing feedback to large language models (LLMs), motivating automated test generation. However, we uncover a trade-off between gener- ating unit test inputs that reveal errors when given a faulty code and correctly predicting the unit test output without access to the gold solution. To ad- dress this trade-off, we propose UTGEN, which teaches LLMs to generate unit test inputs that reveal errors along with their correct expected outputs tests can provide noisy
based on task descriptions. Since model-generann signals (e-g., from incorrectly predicted outputs), we propose UTDEBUG that (i) scales UTGEN via test-time compute to improve UT output predic- tion, and (ii) validates and backtracks edits based multiple generated UTs to avoid overfitting, and helps LLMs debug effectively. We show that UTGEN outperforms other LLM--ased baselines by 7.59% based on a met- ric measuring the presence of both errorrevealing UT inputs and correct UT outputs. When used with UTDEBUG, we find that feedback from UTGEN's unit tests improves pass@1 accuracy of Qwen2.5 32B on HumanEvalFix and our own harder debugging split of MBPP+ by over 3.17% and 12.35% (respectively) over other LLM-based UT generation baselines. Moreover, we observe that feedback from Qwen2.5 32B-based UTGEN model can enhance debugging with frontier LLMs like GPT-4o by 13.8%. Lastly, demonstrate that UTGEN a better judge for code correctness, outperform- ing state-of-the trained 8B reward model by 4.43% on HumanEval+ with best-of-10 sampling using Qwen2.5 7B. Our code and datasets are publicly available https: //gi thub. com/ com/arcchine aarchii/UTeenDebin
1 Introduction
LLM Self-Evaluate
function next
With rapid advancements in train- ing large language models (LLMs; Achiam et al., 2023; Anthropic, 2024; Gemini et al., 2023), enhancing their coding abilities has garnered signif- icant attention (Chen et al., 2021; Li et al., 2022; 2023; Roziere et al., 2023; Guo et al., 2024b, inter alia). How- ever, these models are far from per- fect and much like human-writter code - model-written code contains errors. Human developers often im- prove their code through test-driven development, i.e., identifying failure cases by providing example inputs and their expected outputs- referred to as unit tests (UTs) - to test individ- ual functionalities, reasoning over
palindrome speciied returned
Faulty Code
LLM Cannor Sall-juthe judge
der next www.slllleessss... (eest_platium))
Human: Written
return
Requires Gold Solution
Human Effoort
next, cna (les_ppdd11a))
next wext__tallees____o pidst_p
121 Reored
131 Faled (Ataok Sucoos)
UTDebug
UTGGen (Ours)
Debugging
beds
Faxed Code
def les__ssssess_____ pld(nuu): a Start checking from the next number
current nun + who not is_ Lind ronefcurrent::
Autiomated
-RRferencce-ee free (w/o Gold) V AAttcck Faulty Code
current
return currest
Figure 1: We propose UTGEN, which automatically generates failing unit tests (UTs) for a faulty code (triggering errors) without access to the gold solu- tion. The generated UTs can in turn be used for LLM debugging via UTDEBUG, improving code accuracy.
1

---

Published as a conference paper at COLM 2025
causes of failure, and modifying the code to address the issues (Maximilien & Williams, 2003; Nagappan et al., 2008; Ficco et al., 2011; Beck, 2022). Models have similarly been shown to benefit from iterative debugging based on explicit or implicit feedback stemming from failing unit tests (Zhang et al., 2023; Chen et al., 2023b; Moon et al., 2023). However, the ability to provide feedback and debug incorrect code is often bottlenecked by the availability of (failing) unit tests for given problem.
While several coding benchmarks come with human-written UTs for evaluation pur- poses, these suites of UTs are typically small due to the laborious annotation process (Liu et al., 2024b). Unit test collection is challenging for two reasons: first, it requires sam- pling inputs that are likely to trigger an error. For example in Fig. 1, the unit test: next smallest p1d(1==)=121 would not trigger any error (despite the fact that the code is incorrect for non non-multiples of 10), while another unit test: cirtsssmalllsspp_e_eeeeee padesppl((1)))) (123)=====11) would lead to an incorrect output, revealing a bug in the function. Secondly, UTs require expected outputs (e.g,, 131 in the previous UT), i.e, the desired behavior of the code being tested must be known. Due to these challenges, prior work employs LLMs to generate unit test inputs at random (i.e., without conditioning on faulty code to generate failing inputs) and often uses the gold (correct) code solution for generating outputs (Chen et al., 2023a; Chae et al., 2024). Therefore, these approaches do not scale well at inference time, which requires an online and automaled method for generating UTs as the LLMs solve problems on the fly. To bridge this gap, we pose the following research questions:
RQ1: What are desirable properties for UT generators, and how do we measure them?
RQ2: How well do LLMs perform zero-shol UT generation, and how can we improve them?
RQ3: How do we best use an automated but potentially noisy UT generator to improve code debugging and generation?
To address RQ1, we characterize two desirable properties of unit test generators (in Sec. 3.1): 1) high attack rate, i.e., given a faulty code, the unit test generator should generate inputs that are likely to trigger errors; 2) high output accuracy, ensuring that the UT output is consistent with the task description (and that of correct solution). For instance, in Fig. 1, text.smallest.pp (120) would lead to a lower attack rate, as it does not trigger any errors, while next_ sww.leet..ppdeeeccmmm. (1d))1))==13 does (high attack rate); however, both have high output P
accuracy as in both cases the output is correct. We measure these properties via three intrinsic mefrics: measuring attack rate and output accuracy independently and then, crucially, how often UT generator can generate both failing inputs along with correct UT outputs based only on the problem description and a faulty code. We benchmark the ability of LLMs to act as zero-shot unit test generators and show that coding LLMs generally struggle (cf. Sec. 5.1).
Moreover, addressing RQ2, we find that, without finetuning, zero-shot models often exhibit strong trade-off between attack rate and output accuracy. In other words, the UTs that are most likely to trigger errors (i.e., higher attack rate) are generally more challenging edge cases, making it harder for the model to predict their output (i.e., lower output accuracy). Due to a lack of dedicated datasets for unit test generation in prior work, we introduce UTGEN, a data creation and training recipe (Sec. 3.2) that bootstraps training data for UT generation from existing code generation datasets by perturbing code to simulate errors, generating failing unit test and augmenting it with chain-of-thoo tfohohhtthugt rationales (Wei et al., 2022). We show that training via UTGEN better balances this trade-off and yields higher number of unit tests that have both attacking inputs and correct outputs, with 7.59% absolute improvement over prompting models to generate failing UTss.
Finally, we examine RQ3, utilizing our generated UTs on downstream, i.e, extrinsic tasks: code debugging and code generation. Here, automated UT generation methods face ad- ditional challenges: unlike human -eneratte gold UTs which have correct outputs but require human involvement- generated UT's provide noisy feedback, as the UT might fail to reveal the buggy code's errors or have an incorrectly predicted output. To mitigate this issue, we propose UTDEBUG, an improved multi-turn debugging method that addresses these challenges in two ways (cf. Sec. 3.3): (i) we improve the output accuracy of generated
Here, an 'error' means either syntax/ runntime error, or when the result of the target code does not match the expected output of the UT. We expand on this in Sec. 3.
2

---

Published as a conference paper at COLM 2025
UTs by scaling test-time compute via self-consistency (Wang et al., 2022); (ii) we regularize the debugging process by generating multiple UTs and accepting code edits only if the revised code passes more generated UTs, backtracking edits otherwise. We then plug UTs generated from multiple LLM--asee methods into UTDEBUG in Sec. 5.2, finding that on our most challenging subset of MBPP+ Daletproobh problems, UTDEBUG with UTs generated by UTGEN improves pass@1 accuracy of Qwen2.5 Coder 32B Instruct by 15.07% (absolute) compared to debugging without UTs, and by 4.61% over a zero-shot unit test generation baseline (with similar trends on 8B-scale LLMs). We demonstrate that by generating UTs with UTGEN and computing the rate of passing UTs, we can better judge code correctness than using scores from trained,
8B reward model (RM). For best-of-10 sampling with Qwen2.5 Coder 7B Instruct, UTGEN improves accuracy by 4.43% over the RM on HvlanEval+. Finally, in Sec. 5.5, we highlight the importance of high-quality unit tests generated by UTGEN when debugging with a frontier LLM like GPT--4o (Hurst et al., 2024), finding that using "TGGN-feeddbel. from smaller model, such as Qwen2.5 32B, significantly outperforms self-generated feedback from GPT-4o by nearly 25% (absolute) on the most challenging subset of MBPP+ problems.
2 Related Work
Automatic Unit Test Generation. Manually writing unit tests is laborious and often infeasible (Chen et al., 2023a; Liu et al., 2024b). Consequently, past research explores automatic UT generation (King, 1976; Cadar et al., 2008; Holler et al., 2012; Cha et al., 2015, inter alia). The advent of LLMs has spurred recent efforts in using them for UT generation (Chen et al., 2023a; Schäfer et al., 2023; Liu et al., 2024b). Specifically, Schäfer et al. (2023) and Liu et al. (2024b) focus on generating unit test inputs via prompting frontier LLMs like GPT-4 and /or iterative prompting, assuming access the gold solution. In contrast, our models, trained with UTGEN, generate both input-output UT pairs based on the task description without relying on the gold implementation. While Chen et al. (2023a) also generate input-output UT pairs using standard LLM prompting, their primary focus is code generation - not the quality of generated UTs. In contrast, we directly model the desiderata (or quality) of UTs, and demonstrate its utility code generation and debugging.
LLM Debugging. Using LLMs for debugging faulty code, or program repair, has been extensively studied. Debugging approaches are divided into those training models to debug (Moon et al., 2023; Ni et al., 2024; Chae et al., 2024) and those providing external feedback pretrained models (Chen al., 2023b; Zhang et al., 2023; Olausson al., 2023; Zhong et al., 2024). Both rely on gold unit tests for training or feedback. Thus, UTGEN complements both methods by providing generated unit tests when human-written tests are scarce or unavailable. In Sec. 3.3, we introduce UTDEBUG, debugging pipeline that addresses noisy feedback from inaccurate unit tests through test-time scaling and backtracking, Moreover, in Sec. 5 we show that UTGEN's unit tests can effectively provide feedback to LLMs for code generation and debugging.
3 Unit Test Generation and Automated Debugging
3.1 Background and Task Setup
Given a natural language task description d for a coding task, we focus on generating unit tests (UTs) in the format of input-output pairs that are consistent with the task description d. Our setup is consistent with Chen et al. (2023a) and Jain et al. (2024) who also consider unit tests in the form of input-output pairs generated without utilizing the correct implementation of the function. More generally, our setting is akin to parameterized unit testing (Tillmann et al., 2010) and uses the notion of functional correctness, i.e., measuring correctness by simu- lating an exhaustive set of scenarios (UT inputs) and ensuring that the function performs as expected (as per the problem description d).
Notation and Desiderata. Let d denote the natural language description of the function to be implemented (top yellow box in Fig. 1). We assume that this description specifies the
3

---

Published as a conference paper at COLM 2025
(i) Generate Candidate (Faulty Code)
(UII) Generate Unit Test Outputs
Ievezse the
reverse the
abc ace
cba
input striing.
input string.
eca
Problem Desc.
Gold Code
Faulty Code
Problem Dasc. d
Test Inpui
Ouiput y
Gold
Generate Failing Unit Test Inputs
Rationales of why f+(2)
Why input((be) eba?
aca ace
Inputs for Unit Test
why (ace)
eca?
Let's break down the protien stop by stop:
Rationalize
Faully Code fs
LLM
Training Data
Therefaze, the outout of reverse stt when given
abc
Select cases where Candidate(Input) (Input)
Input
Output
(d. (z. CoT.
input abc
Starting with training data for code generation (problem description and gold code), we create training data for UT generation in three stages: (I) perturbing gold code to generate faulty codes, (II) generating UT inputs and filtering for failing UTs, and (III) generating and relabeling chain-of-thought rationales conditioned on the gold code's outputs.
Figure 2: UTGEN Training Pipeline:
input space X' and output space V. Furthermore, let the set of all functions that correctly solve the task be Fa- Then, a valid unit test (x, for task d is:
x E X, i.e., the input of the unit test is a valid input as per the task description d. fx(x) = y,, Vfr Fa, i.e, y is the expected output as per the task description d, and therefore, is the result one gets by executing any correct implementation.
For example, in Fig. 1, 120 is a valid input, as it is number, whereas "apple" " is not. Similarly, 121 is the expected output of the function (given 120 as input), while 122 would be an invalid output. Thus, (120, 121) is a valid unit test for the task.
Unit Test Generator. Addressing RQ1, we define the desirable properties of an automatic unit test generator Te, parameterized by 0. Ideally, Ta should generate valid unit fests from a task description d, ie., Td(d) + (x.y) without any manual intervention. However, to account for downstream utility of unit tests, we denote a potentially buggy code under testing as fo- If fo E Fa is faulty or implemented incorrectly, a desirable unit test generator should be able to efficiently generate failing unit tests: (d, fb) + (x,y), such that fx(x) # y, i.., a valid unit test input x that uncovers the errors in fr. Moreover, To must also predict the correct UT output y, i.e., the output of the correct code. We study generators of the form (d), which consider only the description, and debugging-style generators of the form (o) which also consider a buggy code solution fo. Empirically, we find that (dd) lacks sufficient context to generate effective error-revealing tests. Therefore, we focus on training UT generators of the form [ad.
3.2 UTGEN: Training LLMs for Unit Test Generation
While prior work focuses on curating training data for improving code generation (Guo et al., 2024a; Muennighoff et al., 2023), there is a general lack of dedicated datasets for training the desired UT generator outlined above. Therefore, to improve along the lines of RQ2, we design, UTGEN, training recipe that bootstraps this data from training datasets for code generation i.e., collection of problem descriptions and their corresponding code.
Problem Descriptions and Target Codes. We start with a collection of coding problems with problem descriptions (d) and gold codes (fr) as illustrated in Fig. 2 (I). Specifically, we use publicly available data from Tulu-3 (Lambert et al., 2024a) due to its large scale and the improvements noted by Lambert et al. (2024a) when finetuning LLMs on coding tasks.? 2 We filter it to focus on Python code with functional abstractions (further details in Appendix B). However, in order to train a unit test generator we would need access to incorrect or faulty
2The code solutions in the Tulu-3 SFT mix have either been written by humans or by frontier models and are thus highly likely to be correct (Lambert et al., 2024a).
4

---

Published as a conference paper at COLM 2025
code that can be debugged, as unit tests must have some error to attack. We obtain these by using the LLM to perturb the reference code solution.
Annotating Unit Tests. As mentioned in Sec. 3.1, one of the goals of the unit test generator is to be able to not only generate valid unit tests, but failing unit tests (that trigger errors). To facilitate this, given a problem description, reference code fr, and buggy candidate code for we sample n different unit test inputs (via the prompts in Appendix H). A unit test (x, fx))) is failing if fx(x) & Fo(x), i.e., if the output of the candidate fails to match the reference output (cf. Fig. 2 (I)). Note that, while the LLM can be used to generate the output of unit test, it can often be inaccurate (Jain et al., 2024; Gu et al., 2024); so to ensure output accuracy, we use the output of the reference code during training. Due to the formalization of UT output prediction as a reasoning word problem, we further explore generating chain-of- thought (CoT; Wei et al., 2022) reasoning before predicting the UT output. To this end, we employ the post-hoc rationalization procedure outlined in Zelikman et al. (2022) given the entire UT (x)),, we ask the LLM generate rationales supporting why fx(x is the output corresponding to the input x. Then, to create the supervision data, we add these rationales as CoTs prior to the output prediction, as illustrated in Fig. (III.. We revisit the discussion of how accurate LLMs are at output prediction during inference in Sec. 5.
Supervised Finetuning. When training LLMs, the input to the LLM is the same prompt used for sampling unit tests (listed in Appendix H) and the output is a failing unit test. We collect nearly 30K training instances for 8B-scale models and roughly 70K instances for training 32B LLMs (details in Appendix B). The goal here is to improve both output accuracy and attack rate jointly via supervised finetuning using the negative log-likelihood loss using basic hyperparameters outlined in Appendix B.
3.3 UTDEBUG: Generated Unit Tests for Debugging
A key difference when using generated unit tests, as opposed to human-generated UTs, is the degree of noise in the feedback. Despite training models via UTGEN or other methods, a generated unit test (X, f) may not be 100% accurate. This can manifest in two ways: 1) the generated UT imput does not fail for the code under debugging frr i.e., f+()) = 2)): the generated UT output is inaccurate, i.e., not consistent with what a gold solution would yield ( + (i)). Both types of errors can negatively impact the utility of unit tests for debuggngg, as shown in Fig. 3 (left). A non-adversaria input might result in faulty code being misclassified as correct and prematurely removed from debugging. Additionally, incorrect outputs can cause false positives, introducing errors to otherwise correct code. Even if the candidate code has bugs, incorrect UT outputs can lead to incorrect feedback, thereby, degrading performance. These issues motivate our RQ3 to incorporate noisy feedback. We propose UTDEBUG, which includes two ways to mitigate noisy feedback from automatically generated unit tests (additional details in Appendix C). We empirically validate the importance of both these components of UTDEBUG in Appendix E.
Boosting Output Accuracy via Test-Time Scaling. Building on past work that has shown the benefits of scaling up inference-time compute (Wang et al., 2022; Lightman et al., 2023; Snell et al., 2024), we improve UT output accuracy by allocating additional computation to the problem. Specifically, we use self-consistency (SC; Wang et al., 2022), whereby, for given UT input, we sample k- 8 output completions (including CoT rationales) and take the most common final UT output (majority vote) as the final answer, as shown in Fig. 3 (top-right). To further boost output accuracy, consistent with Prasad et al. (2024), we upsample UT inputs and only retain those where the final answer gets over 50% of the votes (i.e., 4 votes), discarding the unit test otherwise.
Back-Trackinn and Validation. To handle noisy feedback, it is crucial to know when to abstain or backtrack, e.g., discard edits. This is useful when generated UT outputs are incorrect, leading to faulty feedback, or when correct feedback is not incorporated by the model. Inspired by test-driven development, we accept changes only if the revised code passes the previously failing UT. Moreover, developers often use multiple UTs to detect errors from changes in other parts of the code. This helps prevent overfitting, where code is
5

---

Published as a conference paper at COLM 2025
Issues with Generated Unit Tests
Robust Debugging with Generated Unit Tests
Let's break the step:
Problem Desc: White hunction find the next smallest spacified intagge,
(a) Boosting Output Accuracy via Test-Time Scalling
()) Generated Unit Test Input Does not Fail
intagar.
Gonerated Uiit Irpul
128
+
find the neot
tomt
123
121
Majonit Outpuc
121
Therefore, the outpot of next next_ 121.
Liput 120
nect lest 2201 323
(oold
next www.onoooiooooo Lest ptplltllee 140: wu 141
not railingg!
(b) Back- Back-Tracking and Cross Validation
Poor Rote-
Abstain and Backtrwck Edits
Oebuot
Bound f
Poor Rane 178
Pile 223 but not for 140 run tam sankd
Fauity
del spnt.smmlios diinett
2. 1333 1.51
Code
Fum 1m
240 242
while not 2a adltdnn return mue
(i)) Generated Unit Test Output is not Accurate
mext_asa Lees ILP (222)1
223
Gold
Fule
Initial Code
www.
State Tests
LLM Deloxagtyy Loig
Gorda Ura.
(24(142)
Round 2
Poss Roto: 1008
der sect_.ralleett_ www.emattttttttemnatttt
wille plotcar)
dabugg
roturs
Conrect
Code
Incomeet
Faufty
Code
In Code:
Initaal Code Andlin Uni Tixt
Unii Teat Foodback
Gen, Liik Tepp
Edits
Figure Left: We highlight potential issues with debugging faulty code using generated UTs: (I) non-failing UTs misclassify faulty code as correct; (II) UTs with incorrect outputs produce incorrect feedback and consequently, unsuccessful debugging. Right: We introduce UTDEBUG which (a) uses inference-time scaling to select better UT outputs based on majority vote, and (b) generates multiple UTs for validation, discarding edits when overall pass rate decreases (round 1) and accepting edits when overall pass rate improves (round 2).
modified to pass single unit test but fails others. Therefore, in each debugging round via UTGEN, we generate n UTs. We use one for debugging feedback and accept edits only if the pass rate on the entire set improves (validation); otherwise, we backtrack. This process is shown in Fig. 3 (b), where edits in round 1 are discarded, but those in round 2 improve the test suite a whole and are accepted.
4 Experimental Setup
Models. We demonstrate the effectiveness of UTGEN on three 7-8B scale LLMs across different model families that are adept at coding, namely, Llama3 8B Instruct (AI@Meta, 2024), Llama3.1 8B Instruct (Dubey al., 2024), Qwen 2.5 Coder 7B Instruct in addition to the stronger Qwen 2.5 Coder 32B Instruct model (Hui et al., 2024).
Datasets. We use debugging datasets based on popular LLM coding benchmarks, Hu- manEval (Chen et al., 2021) and MBPP (Austin et al., 2021) along with their extended evaluation suites with more unit tests proposed by by (Liu et al., 2024b). We describe their construction below, with further details in Appendix A.1.
HE+Fix. We take HumanEvalFix (Muennighoff et al., 2024), which has human-introduced errors, and following Ni et al. (2024), augment each problem's 's test suite with overlapping problems from EvalPlus (Liu al., 2024b). This yields 158 problems, each with a faulty solution and suite of private UTs for evaluation -ie., UTs not used for debugging.
MBPP+Fix. We construct a debugging dataset based on the MBPP+ benchmark (Austin et al., 2021; Liu et al., 2024b; Ni et al., 2024). To obtain faulty codes, we sample 16 solutions for each problem from different 7-8B scale models and filter for incorrect solutions based 1
on the private unit tests (described in Appendix A.1). Then, we sample one faulty solution for each problem, resulting in 325 problems with realistic incorrect solutions generated by LLMss. We find such errors are generally harder for models to debug (cf. Sec. 5).
MBPP+Fix (Hard). Additionally, we create a different split from MBPP+ with more subtle errors, logical flaws and missing corner cases making it harder to debug. To this end, we follow a similar generation and filtering process as above but only retain faulty code that passes between 50% 95% of unit tests, resulting in 170 problems with faulty codes.
Evaluation Metrics. Below we describe three intrinsic evaluation metrics for unit test generation (with additional details in Appendix A.2):
Attack Rate. We measure the attacking ability of a UT generator by the frequency with which the output of gold solution f, for input & differs from that of the buggy code fo-
6

---

Published as a conference paper at COLM 2025
Output Accuracy. Measures how often the output of generated unit test f is consistent with the problem description, ie,, generates the same output as the reference code fr. Accuracy n Attack. This metric combines both attack rate and output accuracy and represents how often a unit test generator To generates a useful (i.e. failing unit test for given target code fo while also predicting the output correctly.
We rely on intrinsic metrics during development on validation split from MBPP+ data, e-g. for checkpoint selection and prompt design. Then, we measure the utility and effectiveness of UTGEN by computing the pass@1 code accuracy, i.e, the percentage of codes passing all unit tests on code debugging and generation tasks.
Baselines.
We compare UTGEN against the following (prompts in Appendix H):
No UT feedback: In this baseline, we use self-generated or self-critique feedback, fol- lowing prior work (Madaan et al., 2024; Shinn et al., 2024; Chen et al., 2023b). Specifically, we prompt the model to generate an explanation about the bugs in the target code in addition to determining if the target code is correct, i.e., does not have any more bugs. Randomly-sampled UTs: Consistent with Chen et al. (2023a), we relax the requirement for the LLM to generate failing unit tests, and prompt the model to jointly generate valid unit tests (inputs and outputs) based on the task description, irrespective of the target code, i.e. we sample (x, ~ (d).. We further expand on the comparison with Chen et al. (2023a) in Appendix E. Prompted Failing UTs:
Using the same prompts UTGEN without any training, prompt an LLM to generate a failing UT (with correct output) given the description and the target code. Here, we sample (i, 5) ~ (d, fo).
Note that all U'T-generation baselines along with UTGEN utilize the test-time scaling and backtracking approaches of UTDEBUG highlighted in Sec. 3.3 and exhibit similar run times.
Results and Analysis
5.1 Intrinsic Evaluation of UT Generation
In order to study the inherent UT generation abilities of different models and baselines, we use the intrinsic metrics defined by RQ1 and outlined in Sec. 4 in Table on the most challenging debugging task MBPP+Fix (Hard) averaged over 3 runs.
Trade-offs in Attack Rate and Output Accuracy. In Table 1, we benchmark the zero-shot abilities
Model
Method
Attack Rate Out Acc. Acc. n Attack
Llama3
Random 30.98
46.86 37.10
10.24
of different models on UT gener- ation, as well as our improved training method (corresponding to RQ2). Here, we observe clear tradeoff: prompted and ran- dom unit test generation each optimiz- ing output accuracy or attack rate at the cost of the other metric. While randomly sampled UTs have rela- tively higher output accuracy (i.e., the output of the unit test is correct according to the problem descrip- tion), the random baseline often generate UTs
Prompted
38.04
11.51
8B
UTGEN
41.18
48.24
16.57
Llama3.1
Random
21.76
39.80
9.02
Prompted
40.59
26.86
9.61
8B
UTGEN
41.37
47.75
16.67
Qwen2.5
Random
26.27
57.25
13.53
Prompted
39.80
40.78
14.71
7B
UTGEN
41.96
58.04
20.20
Qwen2.5 Random
25.29
25
11.37
Prompted 51.96
48.43
29.41
32B
UTGEN 56.08
59.22
34.71
Table 1: Evaluation intrinsic metrics of different UT generation baselines and UTGEN across 7-8B dif- ferent model families on MBPP+Fix (Hard) over 3 runs. Higher is better for all three intrinsic metrics.
lacks the ability with inputs that trigger errors (fail- ing UTss). This can be explained by the fact that it is not conditioned on the faulty code fr. On the other hand, when models are prompted to generate a UT that breaks the faulty code in the prompted UT baseline, they generally achieve higher attack rate; however, they lag in terms of output accuracy. For instance, in the case of Qwen2.5 7B, switching from random sampling to prompting failing UTs improves the attack rate by
7

---

Published as a conference paper at COLM 2025
13.53% but decreases the output accuracy by 16.47% hence leading to comparable Acc. N Attack scores (13.53% vs 14.71%). Taken together, this suggests the presence of competing desirable traits of UT generators (cf. Sec. 3.1; RQ1): without training, one baseline often generates trivial unit tests for which the output can easily be predicted (high output accuracy, low attack rate), while the other generates challenging unit tests for which it cannot produce the expected answer (low output accuracy, high attack rate). It also indicates that while models can generate challenging unit test inputs that result in code failure, models struggle with reasoning over correct outputs of failing UT imputs.
UTGEN is Most Effective at Unit Test Generation. We propose to break through this trade-off (thereby addressing RQ2, "How can we improve LLMs' UT generation abilities? ") by training models with UTGEN, where we directly supervise models to have both high output accuracy and high attack rate. Ideally, UTGEN should lead to models that generate unit tests in the "sweet spot" of difficulty, where they are hard enough to trigger errors but not hard that their output cannot be predicted. Table 1 shows that models trained with UTGEN consistently rank highest at jointly generating failing UT inputs with correct outputs (as measured via Acc. Attack in Table 1). For instance, on the strongest coding model in our setting, Qwen2.5 32B, UTGEN obtains the highest attack rate, and output accuracy as well as improves Acc. n Attack score by 5.3% (absolute) over failing UTs generated by prompting and by 23.34% over randomly generated UTs. Similarly, Llama3.1 improves (in terms of attack rate) over mandoml--samplee UTs by 19.61% and the output accuracy of prompted failing UTs by 20.89%, ultimately improving the joint Acc. n Attack score by up to 7.65%. We report the intrinsic metrics for HE+Fix and MBPP+Fix in Appendix D.
5.2 Generated UTs for Code Debugging
UTs from UTGEN are Best for UTDEBUG. Addressing RQ3, we measure how effec-
tive each type of UT generator is in downstream debugging evaluation. From Table 2, we observe that across different LLM fam- ilies, multi-turn debugging with UTDEBUG is more effective when using generated UTs from UTGEN than debugging with UTs generated by the baselines, as well as de- bugging without feedback. For instance, with Qwen2.5 32B, after 3 rounds of de- bugging on MBPP+Fix, UTGEN improves over debugging with randomly-sample UTs by 4.61%, debugging by failing UTs by 3.38%, and debugging without UT feedback by 15.07%. Moreover, on the more chal- lenging MBPP+Fix (Hard) split, UTGEN improves over
Model
UT Method HE+Fix MBPP+Fix (Hard)
No UT
27.22
16.31
11.76
Llama3
Random
51.90
30.46
17.06
Prompted
51.90
28.92
22.94
UTGEN
53.80
37.54
28.82
No UT 31.65
10.15
11.18
Llama3.1
Random
62.03
33.54
13.53
8B
Prompted
56.33
28.00
24.71
UTGEN
67.09
36.92
28.23
No UT
52.53
23.08
16.47
Qwen2.5
Random
79.75
34.77
17.06
UTs by 22.35% and the baseline without UT feed- back by 12.35%. Given that we use the same underlying LLM and similar feedback templates, the results in Table 2 show that UTs generated by UTGEN provide the most useful and effective feedback. Lastly, we find that LLM debugging without any UT feed- back is least effective across model families, thus, establishing that despite noise and is- sues discussed in Sec. 3.3 and Fig. UTDE- BUG with UT-based feedback is more effec- tive than self-ggeerraed feedback. This aligns with past work indicating that LLMs are poor at self-critiquing (Huang et al., 2024).
Prompted
75.32
32.92
24.12
UTGEN
82.91
37.54
29.41
No UT
79.11
39.08
32,94
Qwen2.5 32B
Random
84.81
49.54
22.94
Prompted
85.44
50.77
40.59
UTGEN 88.61
54.15
45.29
Table 2: Evaluating pass@1 accuracies af- ter debugging with UTDEBUG, using UTs generated by UTGEN and other baselines for 3 rounds, MPBB+Fix, and MBPP+Fix (Hard).
HumanEval+Fir (HE+Fix),
Debugging Difficulty Varies Across Datasets. Comparing the post-debugging accuracy across the three datasets in Table 2 suggests different difficulty levels when it comes to LLM debugging. The relatively high accuracies on HE+Fix (especially with Qwen2.5) suggest that int errors in that dataset are obvious and thus too easy for the models to
8

---

Published as a conference paper at COLM 2025
discover and debug. This is also corroborated by the fact that starting codes in this dataset have a pass rate of 0%, ie, fail on all unit tests, suggesting high-level coarse-grained errors, e.g., syntax errors that prevent execution, incorrect function references. On the other hand, MBPP+Fix (Hard) (with an initial pass rate of =75%) appears to be the hardest to debug, with the lowest overall post-debugging accuracy across models up to difference of 53.5% in final accuracies of HumanEvalfix and MBPP+Fix (Hard) for UTGGEN based on Qwen2.5 7B. This in turn suggests that LLMs still struggle with identifying and fixing subtle flaws in generated code, especially in scenarios involving corner cases wherein the model passes some unit tests and fails at the rest.
5.3 Generated UTs for Code Generation
We further demonstrate the effectiveness of generated UTs judging code correctness via Best-of-N sampling (N 10). Given a prob- lem d, we sample N different code solutions, and for each solution, we generate UTs (via UTGEN and baselines Sec. 4 with test-time scaling). In the end, we collate all generated UTs from each method (removing any dupli- cates) and choose the generated code solution that passes the most generated UTs. In other words, we use UTGEN to rerank 10 generated solutions. In addition to comparing to the ran- dom and prompt UT generation baselines, we also rerank according to state-of-the-ar 8B scale reward model (Liu et al., 2024a) on HE+ and MBPP+ (two standard oode-generation datasets). Results in Table 3 reveal that:
Model
Judge Method
HE+
MBPP+
Llama3 8B
54.43
56.00
RM (Liu et al., 2024a)
60.76
59.47
Random UT
61.39
58.93
Prompted UT UTGEN
63.29
60.00
65.12
61.60
Qwen2.5 7B
81.64
65.06
RM (Liu al., 2024a)
83.54
66.67
Random UT
85.44
68.80
Prompted UT
85.71
67.47
UTGEN
87.97
70.13
Table 3: Best-of-10 code accuracy after judg- ing code correctness via generated UTs and external reward model (RM). *Code accu- racy after sampling 1 solution.
Generated UTs Outperform External RMs. In all four settings (models and datasets) in Table 3, we find that LLM-generated UT are better judges for selecting code solutions with higher pass rates compared to trained, state-of-the-art 8B RM.
UTGEN is Better Judge for Code. Across models and datasets, using UTs from UTGEN select code yields the highest performance, outperforming external RM by 4.36%, randomly generated UTs as employed by Chen et al. (2023a) by 3.73%, and prompted UTs by 1.83% on HE+ with Llama3 8B (with similar trends on MBPP+ and using Qwen2.5 7B).
5.4 Comparison to Unit Test Generation by Frontier LLMs
In Table 1 we evaluated open- source LLMs that we trained using UTGEN, and in Sec. 3.3 we applied these models in our UTDEBUG framework for debugging, finding the trained models to be effective. Table 4 compares stronger fron- tier models- - GPT-4o (Hurst et al., 2024) and DeepSeek-V3 (Guo et al., 2024b) - to the best open-source model tested (Qwen2.5 32B). Here, we see that even these stronger and much larger frontier models struggle at the task of generating failing unit tests. First, we find that when prompting models with faulty codes, the attack rate of the generated UTs is slightly over 50% on MBPP+Fix (Hard) dataset, showcasing the inherently challenging nature of isolating corner cases and subtle errors in partially correct code. Furthermore, UTGEN beats both GPT-4o and DeepSeek-V V3 in terms of Acc. n Attack, with gain of 1.38% over both, well as in terms of Attack Rate. On output accuracy, UTGEN is better than DeepSeek-Ve V3 and slightly worse than GPT-4o. Overall, we find that using UT-based feedback even with frontier L.MSs
Model
Method
Attack Rate Out Acc. Acc. n Attack
Random
23.92
57.25 60.39
17.25
GPT-4o
Prompted
54.51
33.33
DeepSeek Random
24.31
63.53
17.84
V3
Prompted
54.31
58.04
33.33
Qwen2.5
Random
25.29
47.25
11.37
Prompted 51.96
48.43
29.41
32B
UTGEN 56.08
59.22
34.71
Table 4: Evaluation of frontier models on intrinsic met- rics on MBPP+Fix (Hard) over 3 runs.

---

Published as a conference paper at COLM 2025
only triggers and identifies errors in 3 times, leaving tremendous room for growth in the ability of models to identify partially incorrect code.
Note that cost is major factor in automated debugging; we show that using UTGEN for debugging in UTDEBUG is successful, but involves generating multiple UTs with self- consistency across several rounds of debugging for each problem (cf. Algorithms and 2). Such calls will quickly become costly on frontier models like GPT-4o and DeepSeek-V3. making relatively smaller models trained with UTGEN more attractive options.
5.5 Importance of Unit Tests with a Frontier Debugger
Finally, we study the importance of unit tests when using a more powerful, frontier model for debugging. To this end, use GPT-4o (Hurst et al., 2024) as the debugger and evaluate its perfor- mance on the MBPP+Fix (Hard) bench- mark. We compare a baseline that does not use UT-execution feedback, where GPT-4o generates its own feedback, or uses feedback generated by Qwen2.5 32B (without any unit tests) against sce- narios where uses UT feedback from the smaller Qwen2.5 32B model, both from prompted baseline and from proposed UTGEN. The results, presented in Table 5, show that even with a significantly stronger debugger model, feedback from high-quality unit tests remains crucial for effective debugging both the prompted baseline and UTGEN outperform the "no UT" baselines by 11.17% and 25% (absolute), respectively. This demonstrates not only that UT feedback is vital even for frontier models, but also that the quality of the unit tests is key factor, as UTGEN outperforms the prompted baseline by a large margin of 13.8%.
Debugger UT Method (Model) MBPP+Fix (Hard)
No UT (GPT-40)
34.71
No UT (Qwen 32B)
32.94
GPT4o
Prompted (Qwen 32B)
45.88
UTGen (Qwen 32B)
59.69
Table 5: Performance of GPT-4o as debugger on MBPP+Fix (Hard) with different UT-generation methods. High-quality UTs from UTGEN signifi- cantly improve the performance of GPT-4o.
Conclusion
We first identified a key trade-off between attack rate and output prediction accuracy when predicting unit tests with models. In light of this trade-off, we introduced UTGEN, a new method for creating training data and teaching models to produce unit tests. This allows us to train models to produce better unit tests, as measured by intrinsic metrics like attack rate and output accuracy. Moreover, finding that existing data contains large numbers of easy errors, we introduce new subset of data with challenging and hard-to-diagnose errors. To enable debugging with automated unit tests, we propose UTDEBUG, wherein we augment our predictor's accuracy with test-time scaling and regularize it using cross-validation and back-tracking procedure that prevents it from overfitting to narrow or incorrect unit test. Additionally, in Appendix F, we demonstrate that these gains persist as we scale the number of generated UTs across datasets. This, combined with UTGEN, results in consistent increases in debugging performance across models, and can be used to improve code generation via best-of-N sampling. Finally, we note that UTGEN is complementary to work on handling real-world programming issues such as Jimenez et al. (2024), which focus on debugging GitHub issues raised by people; in the future, such issues could be identified by unit test generator such as UTGEN.
Acknowledgments
We thank Swarnadeep Saha for insightful discussions in the early phases of this work. Furthermore, we thank the anonymous reviewers and area chairs for their helpful feedback throughout the reviewing process. This work was supported by NSF-CAREER Award 1846185, DARPA ECOLE Program No. 1100012390060, NSF-AÍ Engage Institute DRL- 2112635, and the Center for Al Safety Compute Cluster. Any opinions, findings, and con- clusions or recommendations in this work are those of the author(s) and do not necessarily reflect the views of the sponsors.
10

---

Published as a conference paper at COLM 2025
References
Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, lige Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report. ar preprint ar arXiv:2303.08774 2023.
Al@Meta. Llama 3 model card. 2024. URL https: wet.thh..oommttaaaa... /lama//maammmmmbbb///// main/MODEL.CARD.C md.
Anthropic. The claude 3 model family: Opus, sonnet, haiku. 2024. URL
nttps://ww--con http://wwwcc......oiii..cc anttrropic.coom/deeea000000 http://eaabb.cccaaccccbbabbcebbb 885766777 Model_Card.Claude.33 pdf.
Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al. Program synthesis with large language models. Xrviv preprint wxXv:2108.007322 2021.
Kent Beck. Test driven development: By example. Addison- Professional, 2022.
Cristian Cadar, Daniel Dunbar, Dawson R Engler, et al. Klee: unassisted and automatic generation of high-coverage tests for complex systems programs. In OSDI, volume 8, pp- 209-224, 2008.
Sang Kil Cha, Maverick Woo, and David Brumley. Program-adaptive mutational fuzzing. In 2015 IEEE Symposium on Security and Privacy, pp. 725-741. IEEE, 2015.
Hyungjoo Chae, Taeyoon Kwon, Seungjun Moon, Yongho Song, Dongjin Kang, Kai Tzu- iunn Ong, Beong-wor woong-woo Kwak, Seonghyeon Bae, Seung-wor won Hwang, and Jinyoung Yeo. Coffee-gym: An environment for evaluating and improving natural language feedback erroneous code. Xiv preprint ar 4rXi::2409.19715, 2024.
Bei Chen, Fengji Zhang, Anh Nguyen, Daoguang Zan, Zeqi Lin, Jian-Guang Lou, and Weizhu Chen. Codet: Code generation with generated tests. In The Eleventh International Conference on Learning Representations, 2023a.
Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. Evalu- ating large language models trained on code. ar Xiv preprint ar Stft::217.003377 2021.
Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. Teaching large language models self-debug. arXiv preprint Xxio:2304.05128, 2023b.
Tim Dettmers, Artidoro Pagnoni, Ari Holtzman, and Luke Zettlemoyer. Qlora: Efficient finetuning of quantized llms. Advances in neural information processing systems, 36:10088-
10115, 2023.
Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. The llama herd of models. arXiv preprint ar Xri:::2407 210.28,77 2024.
Massimo Ficco, Roberto Pietrantuono, and Stefano Russo. Bug localization in test-driven development. Advances in Software Engineering, 2011(1):49257,,2) 2011.
Team Gemini, Rohan Anil, Sebastian Borgeaud, Jean-Baptiste Alayrac, Jiahui Yu, Radu Soricut, Johan Schalkwyk, Andrew M Dai, Anja Hauth, Katie Millican, et al. Gemini: family of highly capable multimodal models. Xiv preprint arXie:2312.11805 2023.
Alex Gu, Baptiste Rozière, Hugh Leather, Armando Solar- Lezama, Gabriel Synnaeve, and Sida I Wang. Cruxeval: A benchmark for code reasoning, understanding and execution. ar Xiviv preprint ar Xiv:2440 .0305,, 2024.
Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Y. Wu, Y.K. Li, Fuli Luo, Yingfei Xiong, and Wenfeng Liang. Deepseek-coder: When the large language model meets programming - the rise of code intelligence, 2024a. URL httts://arxiv.ortt wtt.v///b.//b//111111// ha..b//211...19...... 14196.
11

---

Published as a conference paper at COLM 2025
Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Yu Wu, YK Li, et al. Deepseek-coder: When the large language model meets programming the rise of code intelligence. arviv preprint arXie:2401.14196, 2024b.
Christian Holler, Kim Herzig, and Andreas Zeller. Fuzzing with code fragments. In 21st USENIX Security Symposium (USENIX Security 12), pp. 445-458, 2012.
Edward Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen. Lora: Low-rank adaptation of large language models. arXiv preprint ar Xie::206.00%65 2021.
Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, and Denny Zhou. Large language models cannot self-correct reasoning yet. In The Twelfth International Conference on Learning Representations, 2024. URL htttps://openrewee net pet/ffrrum?id-Ikm33Faa
Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Kai Dang, et al. Qwen2. 5-coder technical report. arXiv preprint arXit:2409.12188 2024.
Aaron Hurst, Adam Lerer, Adam P Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Ostrow, Akila Welihinda, Alan Hayes, Alec Radford, et al. Gpt-40 system card. aiv preprint arXie:2410.21276 2024.
Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Ar- mando Solar-Lezama, Koushik Sen, and lon Stoica. Livecodebench: Holistic and contami- nation free evaluation of large language models for code. arXiv preprint arXiv:2403.07974, 2024.
Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R Narasimhan. SWE-bench: Can language models resolve real-world github issues? In The Twelfth International Conference on Learning Representations, 2024. URL net
James C King. Symbolic execution and program testing. Communiications of the ACM, 19(7): 385-394, 1976.
Nathan Lambert, Jacob Morrison, Valentina Pyatkin, Shengyi Huang, Hamish Ivison, Faeze Brahman, Lester James V. Miranda, Alisa Liu, Nouha Dziri, Shane Lyu, Yuling Gu, Saumya Malik, Victoria Graf, Jena D. Hwang, Jiangjiang Yang, Ronan Le Bras, Oyvind Tafjord, Chris Wilhelm, Luca Soldaini, Noah A. Smith, Yizhong Wang, Pradeep Dasigi, and Hannaneh Hajishirzi. Tülu 3: Pushing frontiers in open language model post-training. 2024a.
ChangyyHHaang,
Nathan Lambert, Valentina Pyatkin, Jacob Morrison, LJ Miranda, Bill Yuchen Lin, Khy- athi Chandu, Nouha Dziri, Sachin Kumar, Tom Zick, Yejin Choi, Noah A. Smith, and Hannaneh Hajishirzi. Rewardbench: Evaluating reward models for language modeling, 2024b. URL https://huggingfaeee co ctasea al weweeniieewwar-bennneeee
Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Cheng- hao Mou, Mare Marone, Christopher Akiki, Jia Li, Jenny Chim, et al. Starcoder: may the source be with you! Xiv preprint 2tt.:::::3000660661. 2023.
Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al. Competition-level code generation with alphacode. Science 378(6244)1002-10977 2022.
Hunter Lightman, Vineet Kosaraju, Yura Burda, Harri Edwards, Bowen Baker, Teddy Lee, Jan Leike, John Schulman, Ilya Sutskever, and Karl Cobbe. Let's verify step by step. ar preprint Xio:2305.22 20050, 2023.
Chris Yuhao Liu, Liang Zeng, Jiacai Liu, Rui Yan, Jujie He, Chaojie Wang, Shuicheng Yan, Yang Liu, and Yahui Zhou. Skewor:-reward: Bag of tricks for reward modeling in llms. ar Xiu preprint wxXi::2410.1845 2024a.
12

---

Published as a conference paper at COLM 2025
Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. Is your code gener- ated by chatgpt really correct? rigorous evaluation of large language models for code generation. Advances in Neural Information Processing Systems, 36, 2024b.
Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. Self-refine: Iterative refinement with self-feedbbck. Advances in Neural Information Processing Systems, 36, 2024.
Dakota Mahan, Duy Van Phung, Rafael Rafailov, Chase Blagden, Nathan Lile, Louis Castri- cato, Jan-Philipp Fränken, Chelsea Finn, and Alon Albalak. Generative reward models. Xiv preprint ar Xiv::4410 12832, 2024.
E.M. Maximilien and L.. Williams. Assessing test-driven development at ibm. In 25th International Conference on Software Engineering, 2003. Proceedings., pp. 564-569, 2003. doi:
Seungjun Moon, Hyungjoo Chae, Yongho Song, Taeyoon Kwon, Dongjin Kang, Kai Tzu- iunn Ong, Seung-won Hwang, and Jinyoung Yeo. Coffee: Boost your code Ilms by fixing bugs with feedback. Xiv preprint Xio:2331.007115, 2023.
Niklas Muennighoff, Qian Liu, Armel Zebaze, Qinkai Zheng, Binyuan Hui, Terry Yue Zhuo, Swayam Singh, Xiangru Tang, Leandro von Werra, and Shayne Longpre. Octopack: Instruction tuning code large language models. arXiv preprint arXiv:2308.0712. 2023.
Niklas Muennighoff, Qian Liu, Armel Randy Zebaze, Qinkai Zheng, Binyuan Hui, Terry Yue Zhuo, Swayam Singh, Xiangru Tang, Leandro Von Werra, and Shayne Longpre. Octopack: Instruction tuning code large language models. In The Twelfth Infernational Conference on Learning Representations, 2024. URL https: poattps://ppte /ttp:///ppp//../////eeeeeee wwt/foruuue
PWNSWWZP
Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, and Laurie A. Williams. Realizing quality improvement through test driven development: results and experi- ences of four industrial teams. Empir. Softw. Eng., 1893))289-302, 2008 doi: 10.1007/
$10664-008- (00664-000-9062-2- URL https://doi.onn org////e.rr//////e /00 1007 00000///1666--08-9999555
Ansong Ni, Miltiadis Allamanis, Arman Cohan, Yinlin Deng, Kensen Shi, Charles Sutton, and Pengcheng Yin. Next: Teaching large language models to reason about code execution. In Forty-first International Conference on Machine Learning, 2024.
Theo Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar- Lezama. Is self-repair a silver bullet for code generation? In The Tweeffh International Conference on Learning Representations, 2023.
Archiki Prasad, Weizhe Yuan, Richard Yuanzhe Pang, Jing Xu, Maryam Fazel-Zarandi, Mohit Bansal, Sainbayar Sukhbaatar, Jason Weston, and Jane Yu. Self-consistency preference optimization. Xiv preprint ar arXiv:2411.04100 2024.
Henry Gordon Rice. Classes of recursively enumerable sets and their decision problems. Transactions of the American Mathematical Society, 74(2):358-2) 366, 1953.
Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, et al. Code llama: Open foundation models for code. ar Xiv preprint ar 2ttt::330..19900, 2023.
Max Schäfer, Sarah Nadi, Aryaz Eghbali, and Frank Tip, An empirical evaluation of using large language models for automated unit test generation. ILÉE Transactions on Software Engineering, 2023.
Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning. Advances Neural Information Processing Systems, 36, 2024.
Charlie Snell, Jaehoon Lee, Kelvin Xu, and Aviral Kumar. Scaling Ilm test-time compute opti- mally can be more effective than scaling model parameters. arviv preprint XXiv:4408.03314 2024. URL https: wwtpp/wwwwrr//b//////ee/ 03314.
13

---

Published as a conference paper at COLM 2025
Gemma Team, Thomas Mesnard, Cassidy Hardin, Robert Dadashi, Surya Bhupatiraju, Shreya Pathak, Laurent Sifre, Morgane Rivière, Mihir Sanjay Kale, Juliette Love, et al. Gemma: Open models based on gemini research and technology. arXio preprint arXiv:2403.08295, 2024.
Nikolai Tillmann, Jonathan de Halleux, and Tao Xie. Parameterized unit testing: theory and practice. In 2010 ACM/IEEE 32nd International Conference on Software Engineering, volume 2, pp. 483-484, 2010. doi: 0..114//811025.1110000
Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc V Le, Ed H Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. Self-consistency improves chain of thought reasoning in language models. In The Eleventh International Conference on Learning Repre- sentations, 2022.
Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. Chain-of-thought prompting elicits reasoning in large language models. Advances in neural information processing systems, 35:24824-24887 2022.
Eric Zelikman, Yuhuai Wu, Jesse Mu, and Noah Goodman. STaR: Bootstrapping reasoning with reasoning. Advances in Neural Information Processing Systems, 35:15476-15488, 2022.
Kechi Zhang, Zhuo Li, Jia Li, Ge Li, and Zhi Jin. Self-edit: Fault-aware code editor for code generation. aiv preprint trXiv:2305.04087 2023.
Lunjun Zhang, Arian Hosseini, Hritik Bansal, Mehran Kazemi, Aviral Kumar, and Rishabh Agarwal. Generative verifiers: Reward modeling as next-token prediction. arXiv preprint ar arXix:2408.155 1524400 2024.
Li Zhong, Zilong Wang, and Jingbo Shang. Ldb: A large language model debugger via verifying runtime execution step-by-step. ar arv preprint ar Xixo:2402.16906, 2024.
A Experimental Setup Details
A.1 Debugging Datasets
We use debugging datasets based on popular LLM coding benchmarks, HumanEval (Chen et al., 2021) and MBPP (Austin et al., 2021) along with their extended evaluation suites with more unit tests as proposed by (Liu et al., 2024b).
FE+Fix. We start with the HumanEvalFix dataset containing human-introducedd errors to gold solutions proposed by Muennighoff et al. (2024) (released under MIT license). However, this dataset only uses minimal unit tests to evaluate code correctness (from HumanEval) which has shown to be unreliable (Li et al., 2023), as it can miss errors due to low coverage. Therefore, we filter for problems that overlap with EvalPlus (Liu et al., 2024b) released under Apache-2.0 license, which contains over 80x more unit tests. This yields 158 problems that each have faulty solution and expanded suite of private UTs i.e., UTs not used for debugging - for evaluation.
MBPP+Fix. We construct debugging dataset based on the MBPP+ benchmark (Austin et al., 2021; Liu et al., 2024b; Ni et al., 2024). To obtain faulty codes, sample 16 solutions for each problem from different 7-8 scale models and filter for incorrect solutions based on the private unit tests (described in Appendix A.1). Then, at random corresponding to each problem. This results in a total of 325 problems with incorrect solutions representing realistic errors made by LLM coders. We find such errors are generally more challenging for models to debug (cf. Sec. 5).
select one faulty solution
MBPP+Fix (Hard). To make the debugging task more challenging, we create a different split from MBPP+ with more subtle errors that are harder to debug. We identify these subtle errors by following a similar code generation setup described above, but only retain faulty code that passes between 50% 95% of unit tests, as these partially correct solutions contain less obvious logical flaws and often require handling difficult comer cases. This results in total of 170 problems with faulty codes.
14

---

Published as a conference paper at COLM 2025
HE+Fix. This dataset contains total of 158 problems each with one incorrect human-written code and has an initial pass rate (prior to debugging) of 0%, ie,, all private unit tests are failing. As mentioned in Sec. 4, we use the dataset provided by Muennighoff et al. (2024)² but replace the test set for each problem from the original test suite in HumanEval (Chen et al., 2021) to that in the EvalPlus evaluation suite (Liu et al., 2024b). This increases the average unit tests per problem from 8.17 to 775.18 gold unit tests. Note that we have an automatic UT extraction script for the test code in EvalPlus, and we only retain problems for which this extraction is successful (158 out of 164).
MBPP+Fix and MBPP+Fix (Hard). We begin with 378 problems in the MBPP+ dataset (Liu et al., 2024b)* and follow the same gold UT extraction step described above, discarding problems for which the extraction fails. This leaves us with 375 problems, for which we sample 16 solutions per problem across multiple LLMs: Gemma-7B-IT (Team et al., 2024), Llama3 8B Instruct (AI@Meta, 2024), Llama3.1 8B Instruct (Dubey et al., 2024), Tulu-3 8B SFT (Lambert et al., 2024a), DeepSeek 7B coder (Guo et al., 2024b), Qwen2.5 Coder 7B (Hui et al., 2024). To generate MBPP+Fix, we filter for incorrect solutions (i.e., with at least one failing UT) and then randomly sample one incorrect code per problem. This yields 325 problems in total, each with one faulty code. This dataset has an initial pass rate of 24.21% and an average of 107.45 gold unit tests per problem. In order to construct, MBPP+Fix (Hard), we follow similar process but select only incorrect solutions which pass 50 95% of unit tests. The intuition here is that solutions that are partially correct are often harder to debug than those that are fully incorrect. We then randomly sample one such incorrect solution per problem, yielding dataset of 170 problems with an initial pass rate of 74.83% and an average of 107 49 gold unit tests.
Code Generation. When using generated UTs for improving code generation, we evaluate on HumanEval+ (HE+) and MBPP+ benchmarks proposed in Liu et al. (2024b) released under Apache-2.0 license. As described above, we filter out problems for which we can extract private UTs, yielding 158 problems in HE+ dataset and 375 problems in MBPP+ dataset. For the RM baseline use the latest version of the 8B model based on Llama- 3.1 backbone in Liu et al. (2024a).5 We made this choice based on on rankings on the RewardBench leaderboard Lambert et al. (2024b)
A.2 Evaluation Metrics
Below we describe three intrinsic evaluation metrics for unit test generation: attack rate, oufput accuracy, and accuracy O attack; along with pass@1 accuracy the extrinsic metric to measure LLM's debugging abilities using U'Tffeedacck.
Attack Rate. This metric measures a UT generator Tg's attacking ability, i.e., its ability to generate failing unit test input & for a given buggy solution f.. We measure this by matching if the output of gold reference solution fr for input differs from that of the buggy code f.. Note that this does not take into account the accuracy of the unit test output which we measure separately below. Mathematically, for any dataset D of coding
problems, attack rate is defined as:
100 D
AttackRate
(11)/B())))) JED
Σ 1
where( ~ Told, Po)
Output Accuracy. This metric measures how often the output of a generated unit test ÿ is consistent with the problem description, i.e., generates the same output as the reference gold code fr. Output accuracy does not require the generated unit test to fail. In other words,
9nttps://huggingfaat $nttps://huginggaace
1-88-
15

---

Published as a conference paper at COLM 2025
Algorithm 1 Bui 1dUT: Build Generated Unit Test Suite
Input: d, fo // problem description and buggy code
Params: Number of UTs Number of SC samples k, Unit Test Generator To
Output: Set of Generated UTs U
U1 < Ø Initiaaizzaion, Le., no generated UTT
for UT index
[1,.... ,3 n do // Generates up to distinct UTs from the UT generator To (8), g²) [T, // Sample UTs from UT generator V + initializze vote lookup for self-consistency
for Output index j E [1,-.. ,k] do
of (d, folx() // Sample UTT output
yi extractAns // Extract UT output [1y - v'ly + 1 // Append vote tally G' argmax(v") // Use majority vote for UT output
if v 2 0.5k then // Answer gets over 50% of the vole
41 + (x', Add to generated UT set
if [44] 2 then return U
return !
100 [
OutputAcc
g f(88) deD
Σ
where { ~ (o(
Accuracy n Attack. This metric combines both attack rate and output accuracy and represents how often a unit test generator Te generates a useful falling) unit test for given target code fo while also predicting the output correctly. We calculate this as,
100 x
Acc. O Attack
Σ
[D]
dED
where (X, (d.
Code Accuracy. To evaluate the utility of generated unit tests via code debugging, we follow prior work (Chen et al., 2023b; Chae et al., 2024) in reporting pass@1 code accuracy, i.e, the percentage of codes passing all unit tests after rounds debugging. Note that while we debug with model-generated UTs, we evaluate code accuracy using private UTs.
B UTGEN Training
Preprocessing Tulu Data. We use the Tulu-3 SFT mixture dataset released by Lambert et al. (2024a) which contains a total of 939.3K instances." However, contains mixture of prompts for instruction-follooinng math reasoning, and coding. Therefore, we filter for prompts involving Python coding by regex search for keywords "python" and "def which suit our task setup described in Sec. 3.1. Furthermore, we filter out instances with more than tokens in the prompt and ensure the prompt is a valid unicode string. This results in total of 48.3K instances for which we use the "prompt" as the problem description and extract code from the response of the last turn when multi-turn interactions are present provided that the extracted code executes without any errors issues. Finally, prompt the LLM to be trained with UTGEN to generate 2 corrupted versions of this code to serve as the target code, and for each target code, we make 5 attempts to generate failing unit test inputs and filter out instances that do not have any such UTs. This is followed by the
hhttps: htttt:::///huggngaaaaccc attpaa//aaaaaettttt/a/aaallaaa/a
16

---

Published as a conference paper at COLM 2025
Algorithm 2 UTDebug: Debugging with generated UTs
Input: d, fo // problem description and buggy code
Params: Number of UTs Number of SC samples k, Unit Test Generator To, Number of
debugging rounds m
Output: Debugged code fe
i <- m // Initializing number of rounds left
+
f Initializing edited code with code to debug
acceptEdit <- True // Accept edits to start debugging
while do
i < 1--i-11/ One round of debugging
if acceptEdit = True then
u BdilaUT(dd, fe) // Obtain generated UTs
(xa, va) Ø Initialiize UT for debugging feedback
for (x,y) E l do
if fx() * then
(xar v/a t (x, Failing UT debug
prePass & EvalCode
Get pass rate
if x then No need debug return fe
else Prompt LLM to debug code
f ~ DDMuuuDDeuug Debug Xt, Vdl fe)) // Prompt LLM to debug code with UT feedback postPass +- Eval Code (f (f', 22,
if pastPass prePass then
fe + f // Based on validation on the generated UTs, accept the edits, otherwise discard, ie., backtrack
return fe
Model
UT Method
HE+Fix
MBPP+Fix
Attack Rate Out Ace. Acc. n Attack Attack Rate Out Ace. Acc. n Attack
Random Prompted
89.63
72.97 39.59
72.97
62.56
41.85
24.28
Llama3 8B
95.73
38.78
62.67
29.64
16.41
UTGEN
96.34
53.27
52.04
67.18
42.67
26.87
Random
76.02
63.52
63.52
47.28
36.0
21.33
Llama3.1 8B
Prompted
92.68
34.53
33.89
59.28
19.38
11.08
UTGEN
96.54
56.38
55.76
62.77
43.59
25.54
Random
90.85
87.36
86.47
55.28
52.31
30.38
Qwen2.5 7B
Prompted
93.29
54.55
53.91
62.97
35.29
22.60
UTGEN
96.54
72.90
72.48
65.54
48.62
32.82
Random
84.96
80.19
79,95
54.56
50.17
34.87
Qwen2.5 32B
Prompted 88.82
64.77
63.89
66.87
35.59
27.38
UTGEN 95.93
70.64
69.79
70.36
50.87
40.62
Table 6: Evaluation on intrinsic metrics on HE+Fix and MBPP+Fix for different UT genera- tion methods across multiple models.
rationalization step (with the same LLM to be trained) described in Sec. 3.2 and in Fig. 2, which results in roughly 30K instances for each 7-8B model trained with UTGEN and nearly 70K instances for Qwen2.5 32B.
Training Hyperparameters. We train each model for 10 epochs with a batch size of 16 and learning rate of 5e-6 with cosine learning rate scheduler. Moreover, only compute negative ligeliieldoood loss over the completions. We use LoRA (Hu et al., 2021) with rank of 16, 32 with dropout of 0.05. We perform checkpoint selection based on the intrinsic
17

---

Published as a conference paper at COLM 2025
Acc. n Attack metric. All training and inference is conducted Nvidia's A6000 GPUs taking =20 GPU hours for training and < 0.5 GPU hours for inference (generating one code solution and corresponding UTs with test-time scaling). We train the larger Qwen2.5 32B model on A100 GPUs for roughly 40 GPU hours using QLoRa (Dettmers et al., 2023) with 4-bit quantization.
C Overall Pipeline for UTDEBUG
In Algorithm we describe the process of generating UTs for a candidate buggy code fo using any UT generation method and perform test time scaling for UT output prediction. This then used within UTDEBUG as shown in Algorithm 2, which identifies failing UTs, debugs the target code f. based on feedback from failing UTs over multiple rounds, and returns the debugged (edited code). As illustrated in Fig. 3 (b), edits are accepted only if the newly generated code achieves a higher pass rate than the code before debugging, otherwise the edits are discarded.
Inference Hyperparameters. When sampling multiple UTss and for generating LLMs response to UT feedback we use temperature sampling with temp=0.7 and top-p=0.9.
D Additional Intrinsic Evaluation
Similar to Table 1, we report intrinsic evaluation metrics (cf. Sec. 4) for HE+Fix and MBPP+Fix datasets in Table 6. Consistent with the findings Sec. 5.1, without training, we observe trade-off between attack rate and output accuracy, with randomly sampled UTs showing higher output accuracy whereas the prompted baseline exhibits higher attack rates and vice-versa. Once again UTGEN training best balances this trade-off yielding both high output accuracy and attack rate. However, due to the relative ease of attacking faulty codes in HE+Fix (initial pass rate of 0%) almost any generated UT fails and thus can be used for debugging. This, coupled with the higher output accuracy, results in the random baseline having the highest score on Acc. n Attack. Note that we mitigate this impact downstream performance by using test-time scaling for output prediction in UTDEBUG, which especially boosts the accuracies of targeted UTs generated based the buggy code. On MBPP+Fix, UTGEN consistently yields the highest Acc. n Attack score, followed by the random baseline.
To further validate our intrinsic evaluation metrics, specifically, that both high input attack rate and high output accuracy are key to downstream utility of model-generated unit tests we measure the corre- lation between each property of the UT and whether the UT yielded successful debugging. To this end, we collect oracle metadata on all unit tests generated for MBPP+Fix with Qwen2.5 7B, i.e,, we record if the unit test caused the target code to fail, whether its output was correct, and compute its Somers' D cor- relation with whether the target code was debugged successfully for и = 1 UTs and round of debugging in Table 7. While individually, failing UTs and output correctness show mild correlation with downstream debugging, Table 7 shows that the presence of both attributes yields strong (and the highest) correlation with debugging success and reinforces the motivation for UTGEN and improving unit-test generation ability of LLMs at large.
Intrinsic Metric
Somers' Delta
Attack Rate Output Acc. Acc. n Attack (Both)
0.43
0.34
0.63
Table 7:
Somers' D correlation between intrinsic UT metrics and whether it resulted successful de- bugging. Note, all reported results are statistically significant (p < 0.05).
E Additional Analysis and Results with UTDEBUG
On Test-time Scaling and Backtracking. In Sec. 3.3, highlighted the challenges of debugging with imperfect UTs and suggested remedies to make our debugging pipeline, UTDERUG, robust to noisy feedback from such UTs. We study the effectiveness of these
18

---

Published as a conference paper at COLM 2025
measures, i.e., test-time scaling of UT outputs, and backtracking, debugging with
3 generated UTs for 3 rounds using Qwen2.5 7B on the MBPP+Fix dataset in Table
We show that test-time scaling and back- tracking are crucial for LLM debugging with generated UTs. From Table 8, we ob-
UT Method
Acc.
A
Randomly-sampled (Qwen2.5 7B)
34.77
serve that irrespective of the underlying method for UT generation (either randomly sampled or from UTGEN), removing ei- ther backtracking or test-time scaling hurts downstream performance. First, we find that removing test-time scaling for predict- ing the output of UTs decreases the per- formance of randomly-sampled UTs by 4% and that of UTGEN by 11.4%. Note that larger drop in UTGEN'S performance when removing test-time scaling of UT output prediction is consistent with the findings in Sec. 5.1 that models struggle with reason- ing over correct outputs for failing UT inputs (more often generated by UTGEN). Therefore, test-time scaling in output prediction provides a greater boost for reasoning over challenging inputs (Wang et al., 2022), and consequently, removing yields larger drops for UTGEN. Moreover, Table 8 demonstrates that, without validation on other generated unit tests, LLMs tend to overfit on the unit test contained in the feedback, resulting in up 3.2% drop in performance of UTGEN without backtracking.
-Output Test-time Scaling
30.77
4.0
Backtracking
32.61
2.2
UTGEN (Qwen2.5 7B) -Output Test-time Scaling
37.54
26.15
11.4
-Backtracking
34.38 3.2
Table 8: Ablating components of UTDEBUG's pipeline (cf. Sec. 3.3) for two different unit test generation methods (including UTGEN) on MBPP+Fix using Qwen2.5.
Comparison with CodeT (Chen et al., 2023a) for Debugging. As mentioned in Sec. 2, UTGEN dif- fers from Chen et al. (2023a) that CodeT is designed for code gener- ation by selecting a code from the largest consensus set of codes and independently generated UT (with- out conditioning on code). Alterna- tively, this UT sampling procedure is akin to the randomly-sampled base- line (described in Sec. 4) but the lat- uses self-consistency for predict- ing the UT output. In contrast, UT- GEN is designed for UT generation focusing on the intrinsic quality of uTs as well as their utility for down- stream tasks like code-debugging and best-of-N ranking by conditioning. UT generation
Model
UT Method
HE+Fix MBPP+Fix (Hard)
No UT
52.53
23.08
16.47
Random
79.75
34.77
17.06
Qwen 2.5 7B
Prompted
75.32
32.92
24.12
CodeT
81.65
34.30
21.18
UTGEN
82.91
37.54
29.41
No UT
79.11
39.08
32,94
Random
84.81
49.54
22.94
Qwen 2.5 32B Prompted
85.44
50.77
40.59
CodeT 86.71
46.61
29.41
UTGEN 88.61
54.15
45.29
Table 9: Comparison of pass@1 accuracies after 3
rounds of debugging with UTDEBUG of different UT- generation methods including CodeT (Chen et al., 2023a) - a variant of random UT generation baseline well as UTGEN.
the edge cases of target code. To directly compare against CodeT, instead of using the code generated from CodeTT, we use its unit tests in downstream de- bugging. In Table 9, we scale up CodeT such that uses a similar computational budget as UTGEN and sample n = 3 unit tests for debugging with Qwen 2.5 7B and 32B Code-Instruct models. Across both models and all three debugging datasets, UTGEN outperforms debug- ging with unit tests generated by CodeT by as much 7.54% (absolute) on MBPP+Fix and 15.88% (absolute) on MBPP+Fix (Hard) with Qwen 2.5 32B model. Moreover, CodeT (which generates UTs independent of code being debugged) lags behind the prompted UT baseline in nearly half of the settings, showing that conditioning UT generation on the erroneous code better helps identify and localize bugs.
Scaling with Number of Generated UTs
Thus far, we use 17 3 generated UTs across baselines and models. However, as we described in Sec. 3.3, having multiple UTs can be advantageous because: (i) there is higher likelihood
19

---

Published as a conference paper at COLM 2025
(a) MBPP Fix
(b) MBPP- Fix Hard
Random UT
Random LT
UTGen
UTGen
38
Pass@ Acc.
Paxs@1
34
Num. Generated UTB
Num. Generated UTS
Figure 4: Increasing number of UTs across MBPP+Fix and MBPP+Fix (Hard) using UTs generated by UTGEN and randomly-sampling with Qwen2.5 7B.
of generating failing UT and getting reliable signal for when the code correct, (ii) more robust signal for when to backtrack using validation on the entire generate test suite. We analyze the impact of increasing the number of generated UTs n on downstream accuracy of Qwen2.5 7B after 3 rounds of debugging in Fig. 4. Our findings are as follows:
First, Fig. 4 shows that despite increasing the number of generated unit tests, UTGEN consistently outperforms randomly sampled UTs that may not be failing. This highlights the benefits of generating largeled unit lests conditioned on buggy code in order to trigger
errors and generate appropriate feedback for debugging.
In settings with constrained resources, i.e. sampling S 3 UTs, UTGEN is more effective at identifying errors by up to 3% on MBPP+Fix and 12% on MBPP+Fix (Hard).
On MBPP+Fix (Hard), which contains less obvious errors and is harder to debug, we find that despite scaling to up to 15 generated UTs, the performance gap between UTGEN and randomly-sampa UTs remains at 10% (absolute).
G Discussion
Our work on UTGEN contributes to the broader landscape of verification and feedback generation for LLM--gnnrrted code. While recent work has focused on training verifiers to provide feedback (Mahan et al., 2024; Zhang et al., 2024), a key challenge remains in obtaining high-quality feedback signals for debugging. UTGEN addresses this by directly generating unit tests that can identify problems in code, complementing existing work on how effectively incorporate and present feedback for debugging (Chen al., 2023b; Zhong et al., 2024) along with test-time scaling and backtracking incorporated in UTDEBUG. Our results demonstrate that without a quality signal to determine code correctness and/ or how faulty code is failing (in the form of unit tests), using LLMSs to generate feedback and debug still proves to be challenging. This is one of the first efforts in this direction, and we hope to spark more interest in future work toward LLM-generated unit tests (both input and outputs) that reveal the model's coding errors.
Our approach connects and complements recent work handling real-world program- ming issues. While approaches designed for SWEBench (Jimenez et al., 2024) focus on fixing inownnsssee from Gut by understanding and implementing fixes for bug reports, UTGEN addresses the upstream challenge of automatically discovering potential issues in new code through test generation. Both tasks share core challenge: determining the expected behavior of code without access to correct implementations. This connects to the fundamental concept of simulatability from computability theory (Rice, 1953), where we ask whether program can predict the behavior of another program. Recent work such as Jain et al. (2024) shows that while LLMs can often simulate existing code by tracing execution steps, they struggle more with predicting correct outputs from specifications alone. Our results align with these findings while UTGEN can generate test inputs that trigger errors (high attack rate), predicting correct expected outputs remains challenging (lower output
20

---

Published as a conference paper at COLM 2025
accuracy). This suggests that improving LLMs' ability to reason about intended program behavior from specifications remains a crucial direction for future work. Nevertheless, we find that the modifications made to debugging in UTDEBUG help boost UTGEN's accuracy and account for noise, leading to downstream gains.
H Prompts
In the following pages, we list all the prompts we use in this work.
Prompted and UTGen Prompt for UT generation
You are given a Python function (signature) to solve the following task:
## Task:
{description)
## Code Solution:
{code}
The code solution have provided to you is "iiccoreect". Your job is to give feedback by generating a unit test that
1. Is **valid** input based the task description, ie., acceptable input consistent with task description that a correct program should able to execute.
2. The output enclosed in and is "faithful"* to the task description, iee, the output of the unit test is consistent with what a correct program would return.
3. **Breaks** the given code, i.e., does **oo*** execute to the **correct** output and brings out its mistakes and vulnerabilities.
Provide reasoning for your answer and identify general hypothesis rationale identifying the cause of error. Then provide input and output the unit test consistent with the pattern (hypotheis) you have identified. Note: that you MUST directly write ALL input arguments of the function in the correct order. Skip writing any names of arguments. you MUST enclose the unit test inputs and outputs in.
Respond in the format below:
## Hypothesis
<step-by-step reasoning
>
Error Pattern: <an identified pattern of inputs that yields erroneous incorrect outputs >
## Unit Test
### Input Arguments
<step-by-step reasoning for constructing unit test that fits the error pattern identi- fied above and valid as per the task description >Arguments: (entry (entry.point] point)(<all arguments >)
### Output
<step-by-step reasoning for what *correct** (entry point) would execute to based on the task description and your input above. Make sure your data type of the final answer matches the expected output type of the function.
Output: <your final answer >
21

---

Published as a conference paper at COLM 2025
No UT Feedback Prompt
# Your Task
## Task {prompt)
## Code:
{code}
Based on given task and code, generate feedback that decides whether the code is correct or wrong in the format Feedback: <your feedback >, Always end your feedback with the line "The above code correct." if it is correct, otherwise the feedback should end with "The above code is wrong, please fix it."
UT Generation Prompt for Randomly-sampled UTs
Given a Python function (signature) to solve the following task: [description}
Code Solution:
{code}
The code solution have provided to you is incorrect. Your job is to give feedback by generating unit test input that 1, Valid input based on the task description, i.e., an acceptable input consistent with task description that correct program should be able to execute. 2. Given code will NOT be able to solve and brings out its mistakes and vulnerabilities.
Provide reasoning for your answer and present your response in the format below:
<reasoning
Arguments: {entry (<all)(<all arguments >>
Note that you MUST directly write ALL input arguments of the function in the correct order. Skip writing any names of arguments.
Training UT Gen
Code Corruption Prompt
You are given a Python function {signature) to solve the following task:
## Task
{description}
## Correct Code Solution:
(code}
Assume you TA for programming course. Your task is to corrupt the correct code or implementation of function (entry -pinnt) to introduce realistic errors that can be made by your programming students. Note that you should write code that fails one or more unit tests that this correct would succeed in. Also, give all your reasoning for why your generated code incorrect outside the code block, i.e, "do = leave comments in the code block that reveals the code is incorrect.
Give your output in the format:
<reasoning of error introduced
## Incorrect Code Solution
your generated incorrect code for (entry-point) >
22

---

Published as a conference paper at COLM 2025
UT Feedback Prompt
The above code is incorrect and does not pass the testcase.
Input:
(wrong testcase (estcase.input)
Output: wwwrong.estcase..outpp.
Expected:
(wrong.ters wwngg.testase..xpeeeeeee
Output Rationalization Prompt
## Example
Given Python function check(string) to solve the following task:
Write a python function to accept the strings which contains all vowels.
A user provides an the following input to function. The teacher lets you know that correct function generates the following output.
Input: "BCDEFG"
Output: False
Now ""without" coding up the the function check(string), provide step-by-step soning for why function check when given input of "BCDFG" generates or returns False.
### Reasoning
Let's think step by step.
According to the problem description, given string the check should return accepted if it contains all the vowels and not accepted otherwise.
The vowels (in lower case) that should be present in the string are: "a", "e", "i", "o" and "u".
The given input is "BCDEFG" which contains characters: "b", "c", "d", "e", "f", "g".
While the input string "BCDEFG" contains only vowel "e" and is missing vowels: "a", "1", "o", "u".
Therefore, the output of the function is not accepted.
Test Problem
Given a Python function (signature) to solve the following task:
(description)
A user provides an the following input to function {signature). The teacher lets you know that correct function generates the following output.
Input: (unit input}
Output: (unit_outprn)
Now "without** coding up the the function (signature), provide step-by-step rea- soning for why function (entry point) when given input of (unit input) generates or returns {unit output).
Write your output under header ### Reasoning.
23


Reviews:
[{"review_id": "nVRxPkCKvA", "reviewer": "Reviewer_6enx", "summary": "The paper introduces UTGEN, a framework that trains LLMs generate high-quality unit tests aimed at identifying faults in buggy code without requiring gold-standard implementations. The authors demonstrate a key trade-off between generating test cases that reveal errors (high attack rate) and those that produce correct expected outputs (output accuracy). UTGEN addresses this trade-off by training LLMs with synthetic training data derived from perturbed code and reference outputs. Secondly, the authors introduce UTDEBUG, a debugging framework that leverages the generated UTs for iterative code correction. UTDEBUG incorporates inference-time self-consistency (test-time scaling) and backtracking mechanisms to mitigate the noise in UT feedback. The authors evaluate the system across several benchmarks (e.g., HumanEvalFix and MBPP+Fix), showing improved debugging performance.", "questions": "", "limitations": "", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "- The paper highlights a trade-off in UT generation (attack rate vs. output accuracy) and proposes a data generation and training pipeline (UTGEN) to mitigate it. However, I would say a related work (CodeT) already indirectly addressed this trade-off by generating large-scale test cases and statistically determine better code candidates based on the clusters of candidates grouped by test outputs and the corresponding sizes of the clusters. How is the current approach better than CodeT? \n- Comprehensive Evaluation with different metrics to evaluate the quality of UTs e.g. attack rate, output accuracy, passing rate of generated code\n- The authors apply on different Open-source models (Llama3, Qwen) from 8B to 32B, offering a cost-effective alternative to commercial LLMs.", "reasons_to_reject": "- In the current method, the reliance on artificially perturbed code may limit generalization to organically occurring bugs in real-world repositories. Furthermore, the perturbation is done via LLM and there is not much description of the perturbation method and how realistic the perturbed code is? The authors should at least perform a human study on a subset of data. \n- While UTDEBUG provides a good strategy to handle noisy feedback via CoT+self-consistency and backtracking, the test-time self-consistency and multi-round debugging can be computationally expensive. Note that this computation cost is incurred on top of the cost to train UTGEN to generate test cases. \n- Limited Comparisons with stronger UT Generator baselines: While LLM baselines are well-covered, comparison with stronger baselines such as CodeT is missing.", "questions_to_authors": "- What is the main differences between current approach (UTGEN, UTDEBUG) and CodeT? Can you compare their performance by using the same inference config? \n- How good is the perturbed code created by LLM? Any human study to determine the quality of the dataset? \n- While methods like CodeT can be expensive due to large-scaling test case generation, the computation cost might be cheaper than training a UT generator with UTGEN + test-time scaling with UTDEBUG. Do you have any analysis of the compute cost of the current approach against the baselines like CodeT?", "extra_scores": {}}, {"review_id": "bx5B1LIGzY", "reviewer": "Reviewer_h2jQ", "summary": "**Motivation:**\n\nThe paper addresses the challenge of generating automated unit tests for debugging faulty code generated by large language models (LLMs). Unit tests are crucial for verifying code correctness and guiding debugging, but existing methods often struggle to generate both error-revealing inputs and accurate outputs without access to the correct solution. The authors identify a key trade-off between generating unit test inputs that detect errors and correctly predicting the unit test output.\n\n**Methods:**\n\nTo overcome this trade-off, the authors propose **UTGEN**, a framework that teaches LLMs to generate unit test inputs that reveal errors along with their correct expected outputs. Since LLM-generated tests can be noisy (e.g., incorrect outputs), they also introduce **UTDEBUG**, which scales UTGEN through test-time compute for better output prediction and applies a validation and backtracking mechanism to improve debugging accuracy. UTGEN is trained on code generation datasets by introducing controlled errors, and UTDEBUG improves test accuracy by generating multiple tests and retaining edits that consistently improve pass rates.\n\n**Datasets/Benchmarks:**\n\nThe authors introduced UTGEN, a dataset created by perturbing reference code to simulate faulty scenarios, thereby generating input-output pairs for training and evaluating unit test generation. Additionally, they developed a debugging split of MBPP+  called **MBPP+Fix (Hard)**, which contains more challenging errors by filtering faulty codes that pass between 50% and 95% of unit tests. This dataset emphasizes subtle and logically complex errors, making it more difficult for models to debug compared to existing datasets.", "questions": "", "limitations": "", "rating": 6, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "**Quality and Clarity:**\n\n* The paper is well-written, clearly structured, and provides comprehensive details regarding methodology design, dataset creation, and experimental procedures. \n\n**Novelty and Soundness:**\n\n* The paper addresses a novel research question: the inherent trade-off between the attack rate of unit tests and their correctness.\n* The development of new training datasets for unit test generation addresses a pressing gap in the current research landscape, providing resources that can facilitate further research in this domain.\n* The introduction of the **MBPP-Fix (Hard)** benchmark is helpful, considering the nearing saturation of model performance on existing benchmarks like HumanEvalFix. \n* The experimental evaluation is thorough, exploring multiple downstream applications of generated unit tests. The authors provide a comprehensive analysis and discussion of results.", "reasons_to_reject": "**Methodology Design:**\n\n1. **Insufficient Justification of CoT and Reject Sampling:**\n\n   * The paper leverages Chain-of-Thought (CoT) prompting and reject sampling for dataset generation. However, these techniques are not novel in the context of dataset generation. The paper lacks a deeper analysis or discussion on how these methods fundamentally address the identified trade-off between attack rate and output correctness in unit test generation. Providing concrete evidence or theoretical analysis to substantiate the choice of these techniques would strengthen the methodological soundness.\n\n2. **Evaluation Scope and Baselines:**\n\n   * The current evaluation framework focuses primarily on baseline comparisons involving basic code generation/debugging models. However, several existing works (e.g., CodeT and others) also employ self-consistency or similar techniques for generating unit tests in HumanEval/MBPP-like coding problems. To convincingly demonstrate the effectiveness of UTGEN, the evaluation should be expanded to include more advanced baselines that also utilize generated unit tests for code generation or debugging. This would provide a more comprehensive and rigorous assessment of UTGEN’s relative strengths and limitations.", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "W4G8wCtFaw", "reviewer": "Reviewer_2H95", "summary": "This paper attempts to enhance LLM-based program debugging by improving unit test generation. First, the authors proposed UTGen, a method for creating training data to finetune an LLM-based unit test (UT) generator. Three metrics were used to quantify the effectiveness of a unit test, including (1) the attack rate (i.e., whether the test case reveals the buggy behavior of the program) (2) the output accuracy (i.e., whether the generated output of the unit test is correct) and (3) whether the test case both has a correct output and can attack the program. Additionally, the authors proposed UTDebug, a debugging framework that is robust against noisy test cases. This includes using test-time scaling to improve output accuracy of the generated test cases and discarding edits if they do not improve the pass rate on the entire set of generated test cases. The experimental results show that test cases from UTGen had higher metric scores than baselines. They also worked well with UTDebug to fix buggy programs. Furthermore, there are experiments comparing UTGen with frontier LLMs and using unit tests for reranking generated coding solutions.", "questions": "", "limitations": "", "rating": 6, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "- The finding about the tradeoff between attack rate and output accuracy is interesting, despite not being so surprising.\n- Both UTGen and UTDebug performed well in the experiments.\n- Using unit tests for reranking generated codes is a good application of UTGen.", "reasons_to_reject": "- There is no experiment evaluating the proposed UTDebug framework specifically. We do not know how effective are the two strategies (i.e., test-time scaling and back-tracking), which are pretty computational intensive.\n- The set of generated test cases is used to decide whether to apply an edit. However, this set is unlikely to cover test cases that the original program passes since the fine-tuned UT generator focuses on test cases with high attack rate. Therefore, an approved edit might make the program lose its original correct behavior on ungenerated test cases.\n- The writing and presentation could be improved. \n   - The paper is not self-contained as several important details are in the appendix. For example, although Figure 3 is in the Appendix, it is referred to many times in Section 3.2. In my opinion, it would be better to place Figure 3 in the main content as it helps readers understand the UTGen pipeline. \n   - In contrast, the introduction could be more concise as the current form may overload the readers with details that are difficult to understand until they read the following sections.\n   - The paper mentions “LLMs” several times, but it is unclear whether each mention refers to the LLM used for generating test cases or the LLM used for generating edits (or they are the same model).", "questions_to_authors": "**Questions**\n1. In step 2(b) of Figure 2, can we use more than one test case when prompting the LLM to generate an edit? Why did you prefer using only one test case?\n2. As the debugging is done iteratively, the order of the test cases used may impact the quality of the output program. How did you order the test cases in the experiments?\n3. In Table 2, debugging with randomly-sampled UTs sometimes outperformed the prompted failing UTs. Why was this the case?\n4. If we use a fine-tuned LLM or a frontier LLM to generate edits, will the UTs be less important?\n5. It would be interesting to see the relationship between the intrinsic quality of the test cases and the effectiveness in the downstream debugging task. For instance, what is the difference between the pass@1 scores when the test case has a correct output versus when it has an incorrect output? Or when it can versus cannot attack the program? This will tell us how much the intrinsic evaluation metrics reflect the downstream debugging performance. Do you have any results along these lines?\n\n**Suggestion**\n- The last six lines on page 4 that discusses CoT reasoning seem related more to the training data generation step. So, it may be better to place them before the supervised finetuning paragraph.", "extra_scores": {}}]

Author rebuttal:

Meta-review: This paper presents an approach of unit test generation, and a corresponding pipeline UTDebug to utilize LLM-generated unit tests for debugging. The challenges discussed from this work include whether the generated unit tests can effectively reflect code errors, and whether the test output prediction is accurate. In the evaluation, the paper presents an analysis on the quality of generated unit tests with quantitative metrics to reflect the attack rate and output prediction accuracy. Meanwhile, UTDebug improves the performance and outperforms baselines such as CodeT.

In the rebuttal, the authors added important new experiments to show the effectiveness of their approach, including the comparison to CodeT, and results using the GPT-4o model for debugging. The new analysis and experiments addressed main concerns of the initial submission. The authors should incorporate these changes in the final version.
Decision: Accept