arxiv: 2604.21771 · v2 · submitted 2026-04-23 · 💻 cs.SE

Recognition: unknown

Generalizing Test Cases for Comprehensive Test Scenario Coverage

Binhang Qi , Yun Lin , Xinyi Weng , Chenyan Liu , Hailong Sun , Gordon Fraser , Jin Song Dong

Authors on Pith no claims yet

Pith reviewed 2026-05-09 21:04 UTC · model grok-4.3

classification 💻 cs.SE

keywords test case generalizationtest scenario coverageautomated test generationLLM-assisted testingrequirement inferencemutation testingJava test automationscenario template

0 comments

The pith

A single initial test case encodes enough information about hidden requirements to generate a full set of diverse, valid test scenarios automatically.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper claims that developers often start with one test that captures their intent, but then delay adding others that cover different scenarios implied by the method's design. TestGeneralizer uses an LLM to first deepen understanding of that intent from the test and code, then builds a scenario template and creates multiple concrete instances, and finally produces and cleans up executable tests. On twelve Java projects it raised mutation-based scenario coverage by over thirty percent and LLM-judged coverage by over twenty percent compared with prior tools. If the claim holds, teams could reach thorough testing from far fewer manual starting points and reduce the window in which bugs go uncaught. The approach treats the first test as a living specification rather than just one data point.

Core claim

TestGeneralizer works through three orchestrated stages: it first enhances the LLM's grasp of the requirement and scenario behind the focal method and the given initial test; it then produces a general test scenario template and crystallizes that template into multiple distinct scenario instances; finally it generates executable test cases from those instances and refines them for validity and non-redundancy. When evaluated against three state-of-the-art baselines on twelve open-source Java projects, the resulting test suites achieve higher mutation-based and LLM-assessed scenario coverage than existing methods.

What carries the argument

TestGeneralizer's three-stage pipeline that treats an initial test plus method implementation as input to infer requirements and emit multiple scenario instances.

If this is right

Test suites can reach high scenario completeness starting from a single hand-written example per method.
Bugs that surface only under specific requirement-derived scenarios become detectable earlier in development.
Maintenance effort drops because new tests remain aligned with the behaviors already implicit in the code.
Teams can shift focus from exhaustive manual scenario enumeration to reviewing and selecting among automatically proposed instances.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same inference-from-one-test pattern could be tried on requirement documents or user stories instead of code.
If the generated scenarios were fed back into static analysis, they might expose inconsistencies between the implementation and the original intent.
Integration inside an IDE could let developers accept or reject proposed scenarios interactively, turning the tool into a live requirement elicitation aid.
The approach might generalize to property-based testing by turning the scenario instances into generators rather than fixed cases.

Load-bearing premise

That an LLM can reliably extract the developer's implicit requirement and generate only valid, non-redundant test scenarios from a single initial test and the method implementation without introducing false positives or missing critical cases.

What would settle it

Running the generated tests on a project whose full intended scenario set has already been documented by its original developers and finding that many generated scenarios are either invalid or miss documented behaviors.

Figures

Figures reproduced from arXiv: 2604.21771 by Binhang Qi, Chenyan Liu, Gordon Fraser, Hailong Sun, Jin Song Dong, Xinyi Weng, Yun Lin.

**Figure 2.** Figure 2: Test cases for the focal method setPaint(), covering three test scenarios. The tests follow a common pattern consisting of five parts (highlighted by colored backgrounds), which collectively validate the requirement behind the focal method. 2 Motivation Example In practice, when developers write test cases to validate a requirement, they often follow a recurring pattern to crystallize multiple test scenar… view at source ↗

**Figure 1.** Figure 1: Focal method in ofdrw project [28]. For example, [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

**Figure 3.** Figure 3: Overview of TestGeneralizer: Given a focal method, an initial test, and the codebase, TestGeneralizer [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

**Figure 4.** Figure 4: Generated test scenario template for setPaint() using linearGradientPaint() as the initial test. index constructed in Stage 1, and the retrieved definitions/usages are appended to the prompt before continuing template or instance generation. Test Scenario Instance Generation. A test scenario instance is a concrete test plan for validating a specific behavior of 𝑓 𝑚 in a particular scenario. It is derived f… view at source ↗

read the original abstract

Test cases are essential for software development and maintenance. In practice, developers derive multiple test cases from an implicit pattern based on their understanding of requirements and inference of diverse test scenarios, each validating a specific behavior of the focal method. However, producing comprehensive tests is time-consuming and error-prone: many important tests that should have accompanied the initial test are added only after a significant delay, sometimes only after bugs are triggered. Existing automated test generation techniques largely focus on code coverage. Yet in real projects, practical tests are seldom driven by code coverage alone, since test scenarios do not necessarily align with control-flow branches. Instead, test scenarios originate from requirements, which are often undocumented and implicitly embedded in a project's design and implementation. However, developer-written tests are frequently treated as executable specifications; thus, even a single initial test that reflects the developer's intent can reveal the underlying requirement and the diverse scenarios that should be validated. In this work, we propose TestGeneralizer, a framework for generalizing test cases to comprehensively cover test scenarios. TestGeneralizer orchestrates three stages: (1) enhancing the understanding of the requirement and scenario behind the focal method and initial test; (2) generating a test scenario template and crystallizing it into various test scenario instances; and (3) generating and refining executable test cases from these instances. We evaluate TestGeneralizer against three state-of-the-art baselines on 12 open-source Java projects. TestGeneralizer achieves significant improvements: +31.66% and +23.08% over ChatTester, in mutation-based and LLM-assessed scenario coverage, respectively.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

TestGeneralizer gives a three-stage LLM pipeline for turning one test into broader scenario coverage on real projects, but the metrics leave open whether the gains reflect better requirements or just more LLM output.

read the letter

The core of this paper is TestGeneralizer, which starts from a single developer test and implementation, then runs three LLM-driven stages to pull out implicit requirements, build scenario templates, instantiate them, and refine the resulting test code. The authors test it on 12 open-source Java projects and report gains of about 32% in mutation-based coverage and 23% in LLM-assessed scenario coverage over ChatTester and two other baselines. That pipeline combination and the concrete numbers on actual codebases are what is new here. The work does a reasonable job shifting focus from pure code coverage to requirement-derived scenarios, which matches how developers actually think about tests. The evaluation uses independent projects and external baselines, so the gains are not obviously self-referential in the way some LLM papers can be. The mutation results at least show that the added tests kill more mutants, which is a reproducible signal even if it does not prove perfect requirement alignment. The main soft spots sit in the evaluation details. The LLM-assessed coverage metric is vulnerable to circularity if the same model family or similar prompts are used for both generation and scoring. The abstract and setup give no human-annotated oracle for whether the extracted requirements are accurate or whether the new scenarios are valid and non-redundant rather than plausible-sounding noise. Mutation scores naturally rise when you simply emit more tests, so they do not by themselves confirm that the scenarios match developer intent. No variance, statistical tests, or run counts are mentioned, which makes the percentage deltas harder to interpret. This paper is for researchers working on LLM-supported test generation and for practitioners who want ideas for expanding minimal test suites. A reader already following automated testing literature will get usable pointers on the three-stage structure and the scenario-template step. It is coherent enough and grounded in real projects to deserve peer review rather than a desk reject, though any referee will need to see the full prompt templates, the exact definition of the LLM coverage metric, and preferably some human validation of the generated scenarios before the claims can be taken as settled.

Referee Report

4 major / 1 minor

Summary. The paper presents TestGeneralizer, a three-stage LLM-orchestrated framework that takes a single initial test case plus the focal method implementation, infers the implicit requirement and scenario pattern, generates a scenario template with multiple instances, and produces refined executable tests. On 12 open-source Java projects it reports concrete gains of +31.66% mutation-based scenario coverage and +23.08% LLM-assessed scenario coverage over the ChatTester baseline.

Significance. If the reported coverage gains prove robust and independent of LLM-mediated evaluation loops, the work would meaningfully shift automated test generation from purely structural coverage toward requirement-derived scenario coverage, addressing a documented practical gap where developers add tests only after bugs surface.

major comments (4)

Evaluation section: the abstract and results report aggregate percentage gains (+31.66% and +23.08%) without statistical significance tests, per-project variance, confidence intervals, or raw counts of generated scenarios, rendering the central claim of “significant improvements” difficult to interpret.
LLM-assessed scenario coverage metric (described in the evaluation protocol): because both the generation pipeline (stages 1–2) and the coverage assessor are LLM-based and no independent human-annotated requirement or scenario oracle is provided, the metric risks circularity; apparent gains may reflect prompt alignment rather than genuine requirement coverage.
Stages 1–2 and evaluation protocol: the core assumption that an LLM can reliably extract the developer’s implicit requirement and emit only valid, non-redundant scenario instances from one test plus implementation is unvalidated against human ground truth; without such an oracle the mutation-score improvements cannot be taken as evidence of requirement alignment or absence of false-positive scenarios.
Mutation-based coverage results: while adding more tests naturally raises mutation scores, the paper does not demonstrate that the additional scenarios correspond to the implicit requirements or avoid redundant/false-positive cases, which is load-bearing for the claim that TestGeneralizer produces “comprehensive test scenario coverage.”

minor comments (1)

Abstract: the precise operational definitions of “mutation-based scenario coverage” and “LLM-assessed scenario coverage” are omitted, which would aid immediate comprehension of the reported metrics.

Simulated Author's Rebuttal

4 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback. The comments correctly identify areas where the evaluation can be strengthened with additional statistical rigor and validation. We address each major comment below and commit to revisions that improve transparency and address concerns about circularity and requirement alignment.

read point-by-point responses

Referee: Evaluation section: the abstract and results report aggregate percentage gains (+31.66% and +23.08%) without statistical significance tests, per-project variance, confidence intervals, or raw counts of generated scenarios, rendering the central claim of “significant improvements” difficult to interpret.

Authors: We agree that aggregate percentages alone limit interpretability. In the revised manuscript we will add a per-project table showing raw mutation scores and LLM-assessed coverage for TestGeneralizer and all baselines, together with standard deviations, 95% confidence intervals, and the exact number of scenarios generated per initial test. We will also report Wilcoxon signed-rank test p-values comparing TestGeneralizer against each baseline. revision: yes
Referee: LLM-assessed scenario coverage metric (described in the evaluation protocol): because both the generation pipeline (stages 1–2) and the coverage assessor are LLM-based and no independent human-annotated requirement or scenario oracle is provided, the metric risks circularity; apparent gains may reflect prompt alignment rather than genuine requirement coverage.

Authors: We acknowledge the risk of circularity when both generation and assessment rely on LLMs. The mutation-based results remain independent because they are obtained via PIT, an external mutation tool. To reduce reliance on the LLM metric, we will add a human evaluation on a stratified sample of 50 scenarios across three projects. Two independent annotators will judge whether each generated scenario aligns with the implicit requirement inferred from the initial test and focal method; we will report inter-annotator agreement and the fraction of scenarios judged valid or redundant. revision: partial
Referee: Stages 1–2 and evaluation protocol: the core assumption that an LLM can reliably extract the developer’s implicit requirement and emit only valid, non-redundant scenario instances from one test plus implementation is unvalidated against human ground truth; without such an oracle the mutation-score improvements cannot be taken as evidence of requirement alignment or absence of false-positive scenarios.

Authors: The mutation-score gains are measured by an objective, non-LLM tool and therefore constitute independent evidence that more mutants are killed. Nevertheless, we agree that direct validation of requirement extraction and scenario validity is needed. The human study described above will specifically ask annotators to (a) rate how faithfully each scenario reflects the requirement implied by the initial test and (b) flag any redundant or invalid scenarios. We will include representative examples and disagreement cases in the revision. revision: partial
Referee: Mutation-based coverage results: while adding more tests naturally raises mutation scores, the paper does not demonstrate that the additional scenarios correspond to the implicit requirements or avoid redundant/false-positive cases, which is load-bearing for the claim that TestGeneralizer produces “comprehensive test scenario coverage.”

Authors: All baselines also generate multiple tests, so the observed gains are not explained by test count alone. The human validation study will quantify the proportion of scenarios judged redundant or misaligned with the implicit requirement. In addition, we will report the average number of unique scenarios retained after the refinement stage (Stage 3) to demonstrate that redundancy is actively reduced. revision: partial

Circularity Check

0 steps flagged

No circularity: empirical evaluation against external baselines on independent projects

full rationale

The paper proposes TestGeneralizer as a three-stage LLM-orchestrated framework for generalizing an initial test case into comprehensive scenarios via requirement enhancement, template generation, and executable test synthesis. Its central claims consist of measured improvements (+31.66% mutation coverage, +23.08% LLM-assessed scenario coverage) over the external baseline ChatTester on 12 open-source Java projects. No equations, fitted parameters, self-definitional mappings, or load-bearing self-citations appear in the provided text; the reported gains are obtained by direct comparison to independent methods and artifacts rather than by construction from the method's own outputs or prior author results. The derivation chain is therefore self-contained.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

With only the abstract available, no explicit free parameters, axioms, or invented entities can be extracted; the approach implicitly assumes LLM inference of requirements is sufficiently accurate and that generated scenarios correspond to real developer intent.

pith-pipeline@v0.9.0 · 5601 in / 1178 out tokens · 39346 ms · 2026-05-09T21:04:24.342694+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

46 extracted references · 11 canonical work pages · 1 internal anchor

[1]

Nadia Alshahwan, Jubin Chheda, Anastasia Finogenova, Beliz Gokkaya, Mark Harman, Inna Harper, Alexandru Marginean, Shubho Sengupta, and Eddy Wang. 2024. Automated unit test improvement using large language models at meta. InCompanion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering. 185–196

2024
[2]

Andrea Arcuri and Xin Yao. 2008. Search based software testing of object-oriented containers.Information Sciences 178, 15 (2008), 3075–3095

2008
[3]

Spark authors. [n. d.]. Spark - a tiny web framework for Java 8. https://github.com/perwendel/spark
[4]

Pietro Braione, Giovanni Denaro, Andrea Mattavelli, and Mauro Pezzè. 2017. Combining symbolic execution and search-based testing for programs with complex heap inputs. InProceedings of the 26th ACM SIGSOFT International Symposium on Software Testing and Analysis. 90–101

2017
[5]

Pietro Braione, Giovanni Denaro, Andrea Mattavelli, and Mauro Pezzè. 2018. SUSHI: a test generator for programs with complex structured inputs. In 2018 IEEE/ACM 40th International Conference on Software Engineering: Companion (ICSE-Companion)

2018
[6]

Cristian Cadar, Daniel Dunbar, Dawson R Engler, et al. 2008. Klee: unassisted and automatic generation of high-coverage tests for complex systems programs.. InOSDI, Vol. 8. 209–224

2008
[7]

cron-utils authors. 2018. Infinite loop when daylight savings time starts at midnight #332. https://github.com/ jmrozanec/cron-utils/issues/332

2018
[8]

cron-utils authors. 2018. Test Case for Issue #332. https://github.com/jmrozanec/cron-utils/blob/master/src/test/java/ com/cronutils/Issue332Test.java

2018
[9]

Elizabeth Dinella, Gabriel Ryan, Todd Mytkowicz, and Shuvendu K Lahiri. 2022. Toga: A neural method for test oracle generation. InProceedings of the 44th International Conference on Software Engineering. 2130–2141

2022
[10]

Chunhao Dong, Yanjie Jiang, Yuxia Zhang, Yang Zhang, and Liu Hui. 2025. ChatGPT-Based Test Generation for Refactoring Engines Enhanced by Feature Analysis on Examples . In2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE Computer Society, 746–746. doi:10.1109/ICSE55347.2025.00210

work page doi:10.1109/icse55347.2025.00210 2025
[11]

Eclipse JDT Language Server Authors. 2025. Eclipse JDT Language Server. https://github.com/eclipse-jdtls/eclipse.jdt.ls

2025
[12]

Gordon Fraser and Andrea Arcuri. 2011. Evosuite: automatic test suite generation for object-oriented software. InProceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering. 416–419

2011
[13]

Shuzheng Gao, Chaozheng Wang, Cuiyun Gao, Xiaoqian Jiao, Chun Yong Chong, Shan Gao, and Michael Lyu. 2025. The Prompt Alchemist: Automated LLM-Tailored Prompt Optimization for Test Case Generation. arXiv:2501.01329

work page arXiv 2025
[14]

Patrice Godefroid, Nils Klarlund, and Koushik Sen. 2005. DART: Directed automated random testing. InProceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation. 213–223

2005
[15]

Javier Godoy, Juan Pablo Galeotti, Diego Garbervetsky, and Sebastián Uchitel. 2021. Enabledness-based testing of object protocols.ACM Transactions on Software Engineering and Methodology (TOSEM)30, 2 (2021), 1–36

2021
[16]

Sungmin Kang, Juyeon Yoon, and Shin Yoo. 2023. Large language models are few-shot testers: Exploring llm-based general bug reproduction. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2312–2323

2023
[17]

Myeongsoo Kim, Saurabh Sinha, and Alessandro Orso. 2025. LlamaRestTest: Effective REST API Testing with Small Language Models.Proc. ACM Softw. Eng.2, FSE (2025), 24 pages. doi:10.1145/3715737

work page doi:10.1145/3715737 2025
[18]

Caroline Lemieux, Jeevana Priya Inala, Shuvendu K Lahiri, and Siddhartha Sen. 2023. Codamosa: Escaping coverage plateaus in test generation with pre-trained large language models. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 919–931

2023
[19]

Tsz-On Li, Wenxi Zong, Yibo Wang, Haoye Tian, Ying Wang, Shing-Chi Cheung, and Jeff Kramer. 2023. Nuances are the key: Unlocking chatgpt to find failure-inducing tests with differential prompting. In2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 14–26

2023
[20]

Yun Lin, You Sheng Ong, Jun Sun, Gordon Fraser, and Jin Song Dong. 2021. Graph-based seed object synthesis for search-based unit testing. InProceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 1068–1080

2021
[21]

Yun Lin, Jun Sun, Gordon Fraser, Ziheng Xiu, Ting Liu, and Jin Song Dong. 2020. Recovering fitness gradients for interprocedural Boolean flags in search-based testing. InProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis. 440–451. , Vol. 1, No. 1, Article . Publication date: April 2026. 22 Binhang Qi, Yun Lin, Xin...

2020
[22]

David R MacIver, Zac Hatfield-Dodds, et al. 2019. Hypothesis: A new approach to property-based testing.Journal of Open Source Software4, 43 (2019), 1891

2019
[23]

Simone Mezzaro, Alessio Gambi, and Gordon Fraser. 2024. An empirical study on how large language models impact software testing learning. InProceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering. 555–564

2024
[24]

Zifan Nan, Zhaoqiang Guo, Kui Liu, and Xin Xia. 2025. Test Intention Guided LLM-Based Unit Test Generation. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 1026–1038

2025
[25]

Pengyu Nie, Rahul Banerjee, Junyi Jessy Li, Raymond J Mooney, and Milos Gligoric. 2023. Learning deep semantics for test completion. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2111–2123

2023
[26]

ofdrw authors. 2023. OFD Reader & Writer. Commit Version: 91af2eb. https: //github.com/ofdrw/ofdrw/commit/91af2ebec12cb5eb9a4a4a74b96b2a06504e21e7#diff- 29573571d1af02d4502f7fc750f378c0ba807a539b9cdfac1899c03dd1c6c789R22

2023
[27]

ofdrw authors. 2023. OFD Reader & Writer. Commit Version: 9f82f37. https: //github.com/ofdrw/ofdrw/commit/9f82f37022d9b0d020ca56f40832ebf876b786c4#diff- 94ead98a7ae23957cc9c48bb19f5ab36ee48e0e478b75ed480e31b0b779b9a08R515

2023
[28]

ofdrw authors. 2025. OFD Reader & Writer. https://github.com/ofdrw/ofdrw

2025
[29]

OpenAI. 2025. Introducing OpenAI o3 and o4-mini. https://openai.com/index/introducing-o3-and-o4-mini/

2025
[30]

Carlos Pacheco and Michael D Ernst. 2007. Randoop: feedback-directed random testing for Java. InCompanion to the 22nd ACM SIGPLAN conference on Object-oriented programming systems and applications companion. 815–816

2007
[31]

pitest authors. 2025. State of the art mutation testing system for the JVM. https://github.com/hcoles/pitest

2025
[32]

Binhang Qi, Yun Lin, Xinyi Weng, Yuhuan Huang, Chenyan Liu, Hailong Sun, Zhi Jin, and Jin Song Dong. 2025. Intention-driven generation of project-specific test cases.arXiv preprint arXiv:2507.20619(2025)

work page internal anchor Pith review Pith/arXiv arXiv 2025
[33]

Binhang Qi, Hailong Sun, Wei Yuan, Hongyu Zhang, and Xiangxin Meng. 2021. Dreamloc: A deep relevance matching- based framework for bug localization.IEEE Transactions on Reliability71, 1 (2021), 235–249

2021
[34]

Max Schäfer, Sarah Nadi, Aryaz Eghbali, and Frank Tip. 2023. An empirical evaluation of using large language models for automated unit test generation.IEEE Transactions on Software Engineering(2023)

2023
[35]

Koushik Sen, Darko Marinov, and Gul Agha. 2005. CUTE: A concolic unit testing engine for C.ACM SIGSOFT Software Engineering Notes30, 5 (2005), 263–272

2005
[36]

Jiho Shin, Sepehr Hashtroudi, Hadi Hemmati, and Song Wang. 2024. Domain Adaptation for Code Model-Based Unit Test Case Generation. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1211–1222

2024
[37]

Deepika Tiwari, Yogya Gamage, Martin Monperrus, and Benoit Baudry. 2024. PROZE: Generating Parameterized Unit Tests Informed by Runtime Data. In2024 IEEE International Conference on Source Code Analysis and Manipulation (SCAM). 166–176. doi:10.1109/SCAM63643.2024.00025

work page doi:10.1109/scam63643.2024.00025 2024
[38]

Deepika Tiwari, Long Zhang, Martin Monperrus, and Benoit Baudry. 2021. Production monitoring to improve test suites.IEEE Transactions on Reliability71, 3 (2021), 1381–1397

2021
[39]

Michele Tufano, Dawn Drain, Alexey Svyatkovskiy, Shao Kun Deng, and Neel Sundaresan. 2020. Unit test case generation with transformers and focal context.arXiv preprint arXiv:2009.05617(2020)

work page arXiv 2020
[40]

Vasudev Vikram, Caroline Lemieux, Joshua Sunshine, and Rohan Padhye. 2023. Can large language models write good property-based tests?arXiv preprint arXiv:2307.04346(2023)

work page arXiv 2023
[41]

Hongtai Wang, Ming Xu, Yanpei Guo, Weili Han, Hoon Wei Lim, and Jin Song Dong. 2025. RulePilot: An LLM-Powered Agent for Security Rule Generation. arXiv:2511.12224 [cs.CR] https://arxiv.org/abs/2511.12224

work page arXiv 2025
[42]

Jin Wen, Qiang Hu, Yuejun Guo, Maxime Cordy, and Yves Le Traon. 2025. Variable Renaming-Based Adversarial Test Generation for Code Model: Benchmark and Enhancement.ACM Transactions on Software Engineering and Methodology (2025)

2025
[43]

Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. 2024. Fuzz4all: Univer- sal fuzzing with large language models. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–13

2024
[44]

Chen Yang, Junjie Chen, Bin Lin, Jianyi Zhou, and Ziqi Wang. 2024. Enhancing LLM-based Test Generation for Hard-to-Cover Branches via Program Analysis.CoRRabs/2404.04966 (2024)

work page arXiv 2024
[45]

Zhiqiang Yuan, Mingwei Liu, Shiji Ding, Kaixin Wang, Yixuan Chen, Xin Peng, and Yiling Lou. 2024. Evaluating and Improving ChatGPT for Unit Test Generation.Proc. ACM Softw. Eng.1, FSE, Article 76 (jul 2024), 24 pages. doi:10.1145/3660783

work page doi:10.1145/3660783 2024
[46]

Junwei Zhang, Xing Hu, Shan Gao, Xin Xia, David Lo, and Shanping Li. 2025. Less Is More: On the Importance of Data Quality for Unit Test Generation.Proc. ACM Softw. Eng.2, FSE, Article FSE059 (June 2025), 24 pages. doi:10.1145/3715778 , Vol. 1, No. 1, Article . Publication date: April 2026

work page doi:10.1145/3715778 2025