pyMethods2Test: A Dataset of Python Tests Mapped to Focal Methods

Idriss Abdelmadjid; Robert Dyer

REVIEW 4 major objections 6 minor 23 references

pyMethods2Test: A Dataset of Python Tests Mapped to Focal Methods

T0 review · 4 major / 6 minor · reviewed 2026-08-08 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A new dataset maps over 2 million Python unit tests to the specific methods they exercise, the first at this scale for Python.

desk verdict A genuinely useful first Python test-to-focal-method dataset, but the mapping quality is unmeasured and the paper should not be accepted without a validation study. read the letter →

arxiv 2502.05143 v1 pith:D32BD27Y submitted 2025-02-07 cs.SE

Idriss Abdelmadjid , Robert Dyer This is my paper · ORCID

classification cs.SE

keywords Pythonunittestingfocalmethodtest-to-codetraceabilityPytestunittestLLMtrainingsoftwaredataset

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

Python lacks a large-scale dataset linking unit tests to the methods they test, even though such links are exactly what LLMs need to learn test generation. This paper introduces pyMethods2Test, built from 88,846 open-source repositories that use Pytest or unittest, containing over 2 million test-to-focal-method mappings drawn from more than 22 million test methods. The authors argue this is the first dataset of its kind for Python and provide not only the mappings but also generated context—class declarations, constructors, other method signatures, and attributes—intended for LLM prompts. A sympathetic reader would care because it fills the Python gap left by Java-only datasets and enables training, mining, and tooling applications that previously had no data foundation.

What carries the argument

The focal-mapping heuristic is the load-bearing mechanism. It works in stages: first, detect test files by imports of pytest/unittest and filename patterns; second, enumerate test methods by the 'test' prefix; third, collect all called methods in each test and filter out library calls using project import information; fourth, pick a focal file from imports, filename suffix such as test_foo.py to foo.py, or fuzzy match; fifth, identify a focal class by name or AST position; and sixth, identify the focal method by checking whether the test method name ends with the called method's name, falling back to fuzzy matching with a cutoff of 50. A final script assembles 'focal context'—the focal class declaration, the focal method body, constructor, other method signatures, and class or instance attributes—so each entry can be fed directly to an LLM.

What would settle it

Take a random sample of, say, 200 mapped entries from the released JSON, have two annotators read each test and its mapped focal method, and count how often the mapped method is the primary method under test; if the agreement-corrected precision falls well below an acceptable threshold such as 80 percent, the central claim of providing reliable test-to-focal-method mappings would be undermined.

Watch

Extended reading notes

Core claim

The central claim is that a heuristic pipeline—AST parsing, import-based identification of test files, filtering called methods to project-internal methods, and fuzzy string matching with a manually set cutoff—can recover explicit traceability from Python tests to focal methods at scale. The paper reports 22,662,037 test methods found, of which 2,198,378 (about 10 percent) are mapped to a focal method, and presents this as the first large-scale Python dataset of its kind. The dataset is released in JSON with repository, file, line, class, and method metadata, plus a script that generates focal context in the style used for transformer-based test generation. The intended use is training LLMs to generate unit tests for Python, with the mappings giving the model the tested method and surrounding class information as input.

Load-bearing premise

The load-bearing premise is that a test method's name ending with, or fuzzy-matching, the name of a called method identifies the single focal method; because this is never checked against human-labeled or otherwise verified mappings, the quality of the 2 million traceability links is unknown.

Editorial extensions

If this is right

LLM training for Python unit-test generation now has a large supervised signal: each mapping pairs a test method with the exact method it exercises, plus class-level context for the prompt.
Researchers can mine the dataset to measure real-world testing practice, including the relative adoption of the two frameworks, the prevalence of test smells, and common test design patterns across nearly 90,000 projects.
Tool builders can use the explicit links for coverage-gap analysis, fault localization, and test-case recommendation, since the focal file, class, method, and locations are all included.
Educators can draw on authentic, varied test examples from real projects for teaching and assessment.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Inference: the 10 percent mapping rate means 90 percent of test methods are left unused; whether the mapped subset is representative of all Python testing matters for any downstream training, and the paper does not report this representativeness.
Inference: because the fuzzy-match cutoff of 50 was chosen by manual inspection and never validated against ground truth, a small precision audit could substantially change how much trust users place in the traceability links.
Inference: the released context-generation script could be extended to include call graphs or data-flow snippets, which might improve LLM-generated tests beyond the current class-level context, but this extension is not in the paper.
Inference: the dataset enables a direct cross-language experiment: train a test-generation model on this Python data and compare against a model trained on the Java predecessor, measuring whether the Python-specific focal context changes generation quality.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Quick take: pyMethods2Test is a real artifact — the first large-scale Python dataset of tests mapped to focal methods, with 2.2M mappings from 88K repos and public release on Zenodo. That is genuinely valuable. But the central claim that these links are reliable traceability is not supported by any measured precision or recall. The stress-test note has it right: this is the difference between a validated dataset and a large set of plausible guesses.

What the paper does well: the pipeline is described in enough detail to replicate, the context-generation script is a sensible addition for LLM use, and the Limitations section is honest — it plainly admits some mappings may be inaccurate. The citation pattern is fine; Methods2Test, TestRoutes, and Defects4J are the right anchors. Even if you ignore the focal-method links entirely, the raw corpus of 22M test methods with metadata is useful on its own.

The soft spot is load-bearing. The focal-method heuristic in Section II-D checks whether the test method name ends with a called method's name, with a fuzzy fallback at a cutoff of 50 chosen by manual inspection. No precision, recall, or manual audit is reported for any stage. The paper's own limitations acknowledge that tests validating multiple methods or calling auxiliary methods may be mistargeted. With only 10% of test methods mapped, there is also a selection effect: the mapped subset skews toward conventionally named tests, which may not represent typical Python test code. That bias is unquantified. For LLM training, noisy labels are sometimes tolerable, but the paper advertises "explicit traceability links," and that claim is currently unverified.

This is not a takedown. The artifact deserves attention, and a moderate revision could fix the gap. Who is this for? People building Python test generators and researchers mining test practices; they will get value, but they should treat the mappings as candidate labels, not ground truth. I would cite it as a resource with a caveat.

Recommendation: send it to peer review. It deserves referee time. The reviewers should require a validation study — a manually labeled sample with per-stage precision/recall and a sensitivity check on the fuzzy cutoff. Without that, the headline number carries little evidential weight.

Referee Report

4 major / 6 minor

Summary. The paper presents pyMethods2Test, a dataset of over 2.2 million focal-method mappings extracted from 88,846 open-source Python repositories. The authors use Python's AST module to identify test methods in files using Pytest or unittest, collect methods called from each test body, and apply a pipeline of heuristics (import-based filtering, filename matching, class matching, and fuzzy string matching) to map each test method to a single focal method. The dataset includes position information for test and focal methods, a focal class when present, and a separate script that generates contextual information (class declaration, constructor, other method signatures, attributes) intended for LLM training. The paper claims this is the first large-scale Python dataset of its kind and describes applications in test generation, mining testing practices, and education.

Significance. If the traceability links are accurate, pyMethods2Test would be a valuable resource for training LLMs for Python unit test generation and for empirical studies of test practices. The scale (2.2M mappings, 22.7M test methods) and the decision to release both the focal data and the intermediate raw data are clear strengths, as is the public availability on Zenodo. However, the central contribution is a set of automatic mappings, and the paper provides no quantitative evidence that those mappings are correct. Every downstream use named in Section III—LLM training, test generation, mining test practices—assumes that the focal_method link is reliable. Because that reliability is unmeasured, the significance of the dataset is currently conditional: the raw test corpus is useful irrespective of the mapping accuracy, but the headline traceability product is not yet validated.

major comments (4)

[Section II-D and Section IV] The paper reports no precision, recall, or any comparison against ground truth for the focal-method mapping heuristic. The only calibration evidence is the fuzzy cutoff of 50 'based on a manual inspection,' and the Limitations section itself concedes that 'some mappings may still be inaccurate.' Since the dataset's core claim is to provide explicit traceability links, the absence of any accuracy measurement leaves the headline contribution unsubstantiated. I request a manual audit of a random sample of mappings (with a defined sample size, a protocol for determining ground truth, and inter-rater agreement) and stage-wise precision/recall figures for focal file, focal class, and focal method identification.
[Section II-D] The fuzzy-match cutoff of 50 is a free parameter tuned on the same data used to produce the dataset, and the paper does not analyze how the number or correctness of mappings varies with this threshold. This is a correctness risk because the 10% mapping rate (2,198,378 out of 22,662,037 test methods) may be highly sensitive to this hand-chosen value. Please provide a sensitivity analysis over a range of cutoff values and, if possible, an independent validation set for choosing the threshold.
[Section II-A, II-B, and Section IV] The heuristic's coverage and failure modes are not quantified. The paper does not report how many test methods are discarded at each stage (e.g., no matching local imports, zero or multiple candidate focal files, no invoked method name matching the test name, or class-matching failure), nor how the resulting mapped subset is biased relative to the full 22.7M test methods. Because downstream users need to know when a mapping is reliable, I ask for a breakdown of non-mapping reasons and a characterization of the mapped subset (e.g., project size, naming conventions, framework distribution).
[Section II-D and Section IV] The heuristic assumes that the focal method's name is lexically related to the test method's name, and the Limitations section acknowledges that this 'may overlook scenarios where a test validates multiple methods or calls auxiliary methods.' The paper should quantify how often a test method calls multiple non-local methods and describe how the heuristic chooses among them; this is a central decision for the mapping and its accuracy should be explicitly evaluated rather than only described as a potential limitation.

minor comments (6)

[Section II-D] The sentence 'we consider all method invocations in the test method to be a non-library method' is confusing; the intended meaning appears to be that each invoked method is treated as a candidate non-library method before filtering. Please rephrase for clarity.
[Figure 1] The JSON example contains a line break inside the string value for 'focal_class' ('gordon.metrics.ffwd.\nUDPClientProtocol'), which could mislead readers parsing the example. The figure should show the actual output format.
[Section V] The prior Java dataset is referred to as both 'Method2Test' and 'Methods2Test' in the text; please standardize the name to match the cited reference [11].
[Section II-C] The description of focal class matching ('based on name and then fall back to using position-based information by walking back up the AST') is underspecified; provide the concrete rules or an algorithm outline so that the process is reproducible.
[Section VI] The claim of being 'the first Python dataset with more than 2 million methods mapped from almost 90k open-source projects' should be supported with an explicit comparison to existing Python test corpora or test-to-code traceability datasets, to verify the novelty claim.
[Table I] The aggregate counts in Table I give no sense of per-repository distribution; consider reporting medians and quartiles for the numbers of test methods and focal mappings, since a few very large repositories could dominate the totals.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: pyMethods2Test is an observational/heuristic dataset artifact with no derived prediction whose output is equivalent to its inputs.

full rationale

The paper makes no derivation claim of the kind the circularity pass targets. Its central contribution is a constructed dataset: repositories are mined, test methods are located by framework-specific naming rules, and focal methods are mapped by the Section II-D heuristic that checks whether the test method name ends with an invoked method's name, with a fuzzy-match fallback at cutoff 50 chosen 'based on a manual inspection.' This is an empirical pipeline, not a model that fits parameters to data and then predicts that same data. The mapping definition and the mapping output are not the same quantity: the heuristic consumes test method names, called-method sets, imports, and filenames, and emits a focal method, so there is no equation in which the output equals an input by construction. The unvalidated precision of the 2.2M mappings is a legitimate correctness/validity concern, and the paper itself acknowledges in Section IV that 'some mappings may still be inaccurate' and that the naming-based assumption 'may overlook scenarios where a test validates multiple methods.' That is missing empirical validation, not circular reasoning. The only self-citations are [14] (the Zenodo dataset artifact) and [15] (the Boa infrastructure used to obtain the 2.6M-repository corpus). [15] is a data-source citation by one of the present authors, but the Boa corpus is an externally maintained, independently reproducible repository collection and is not invoked as a proof of any claim; the paper's own heuristic does the mapping work. No uniqueness theorem is imported, no ansatz is smuggled via citation, and no known result is renamed. The focal-context construction follows Tufano et al. [16] for ordering, which is standard prior work and not load-bearing for the mapping claim. Therefore the appropriate finding is no significant circularity with score 0.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The pipeline relies on several unvalidated assumptions about Python code and test naming. The most critical is that test names encode the focal method name. Additional assumptions concern AST parsing correctness and import-based file identification. No independent validation of the mappings is provided.

free parameters (1)

Fuzzy matching cutoff = 50
In Section II-D, the authors state the cutoff was determined 'based on a manual inspection' of test-method naming patterns. This value directly affects which methods are mapped and is not validated on a held-out set.

assumptions (3)

domain assumption Python AST parsing correctly identifies classes and methods in source files.
The entire pipeline relies on Python's ast module to extract method positions and names. Misparsing due to syntax errors or dynamically generated methods would break the mapping.
domain assumption Test files can be identified by the presence of pytest/unittest imports and filename patterns.
Section II-A assumes that projects using these frameworks import them in test files. Some tests may use these frameworks without importing them directly (e.g., via conftest), and some non-test files may import them.
ad hoc to paper Method names in tests are lexically related to the names of the methods they test.
This is the core heuristic in Section II-D: the focal method is found by checking if the test method name ends with the invoked method's name or fuzzy-matches it. This assumption is not generally true; tests may have arbitrary names.

how reviews work

0 comments

Cite this review

Pith. "Pith review of pyMethods2Test: A Dataset of Python Tests Mapped to Focal Methods." pith.science (2026). https://pith.science/paper/D32BD27Y

@misc{pith2026250205143,
  author       = {Pith},
  title        = {Pith review of: pyMethods2Test: A Dataset of Python Tests Mapped to Focal Methods},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/D32BD27Y}},
  note         = {Machine review of arXiv:2502.05143}
}

read the original abstract

Python is one of the fastest-growing programming languages and currently ranks as the top language in many lists, even recently overtaking JavaScript as the top language on GitHub. Given its importance in data science and machine learning, it is imperative to be able to effectively train LLMs to generate good unit test cases for Python code. This motivates the need for a large dataset to provide training and testing data. To date, while other large datasets exist for languages like Java, none publicly exist for Python. Python poses difficult challenges in generating such a dataset, due to its less rigid naming requirements. In this work, we consider two commonly used Python unit testing frameworks: Pytest and unittest. We analyze a large corpus of over 88K open-source GitHub projects utilizing these testing frameworks. Using a carefully designed set of heuristics, we are able to locate over 22 million test methods. We then analyze the test and non-test code and map individual unit tests to the focal method being tested. This provides an explicit traceability link from the test to the tested method. Our pyMethods2Test dataset contains over 2 million of these focal method mappings, as well as the ability to generate useful context for input to LLMs. The pyMethods2Test dataset is publicly available on Zenodo at: https://doi.org/10.5281/zenodo.14264518

Figures

Figures reproduced from arXiv: 2502.05143 by the authors.

**Figure 1.** Example of focal JSON data More specifically, the fields included are: • test_file: The file path of the test file. • focal_file: The file path of the focal file (the file being tested). • methods: A dictionary, where keys are test method names and values are mapped data for that test. • line: The starting line of the method. • line_end: The ending line of the method. • indent: The indentation level of the method, w… view at source ↗

**Figure 2.** Example focal context from spotify/gordon in the Python ecosystem, the exclusion of other, less popular, or custom testing frameworks may leave some testing practices unrepresented, potentially limiting the dataset’s generalizability to projects using frameworks outside of Pytest and Unittest. Additionally, the dataset assumes that methods with names similar to the test method and called within its body are the pri… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 22 canonical work pages

[1]

A survey on unit testing prac- tices and problems,

E. Daka and G. Fraser, “A survey on unit testing prac- tices and problems,” in 2014 IEEE 25th International Symposium on Software Reliability Engineering , 2014, pp. 201–211

work page 2014
[2]

Refactoring test code,

A. Deursen, L. M. Moonen, A. Bergh, and G. Kok, “Refactoring test code,” CWI (Centre for Mathematics and Computer Science), NLD, Tech. Rep., 2001

work page 2001
[3]

Understanding myths and realities of test-suite evolution,

L. S. Pinto, S. Sinha, and A. Orso, “Understanding myths and realities of test-suite evolution,” in Proceedings of the ACM SIGSOFT 20th International Symposium on the F oundations of Software Engineering, ser. FSE ’12. New Y ork, NY , USA: Association for Computing Machinery, 2012

work page 2012
[4]

Evosuite: automatic test suite generation for object-oriented software,

G. Fraser and A. Arcuri, “Evosuite: automatic test suite generation for object-oriented software,” in Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on F oundations of Software Engi- neering, ser. ESEC/FSE ’11. New Y ork, NY , USA: As- sociation for Computing Machinery, 2011, p. 416–419

work page 2011
[5]

Randoop: feedback- directed random testing for Java,

C. Pacheco and M. D. Ernst, “Randoop: feedback- directed random testing for Java,” in Companion to the 22nd ACM SIGPLAN Conference on Object-Oriented Programming Systems and Applications Companion , ser. OOPSLA ’07. New Y ork, NY , USA: Association for Computing Machinery, 2007, p. 815–816

work page 2007
[6]

Whole test suite generation,

G. Fraser and A. Arcuri, “Whole test suite generation,” IEEE Transactions on Software Engineering , vol. 39, no. 2, pp. 276–291, 2013

work page 2013
[7]

A comparative analysis of large language models for code documentation generation,

S. S. Dvivedi, V . Vijay, S. L. R. Pujari, S. Lodh, and D. Kumar, “A comparative analysis of large language models for code documentation generation,” in Proceed- ings of the 1st ACM International Conference on AI- Powered Software, ser. AIware 2024. New Y ork, NY , USA: Association for Computing Machinery, 2024, p. 65–73

work page 2024
[8]

Chatunitest: A framework for llm-based test gener- ation,

Y . Chen, Z. Hu, C. Zhi, J. Han, S. Deng, and J. Yin, “Chatunitest: A framework for llm-based test gener- ation,” in Companion Proceedings of the 32nd ACM International Conference on the F oundations of Software Engineering, ser. FSE 2024. New Y ork, NY , USA: As- sociation for Computing Machinery, 2024, p. 572–576

work page 2024

Show all 23 references

[9]

LLaMA- Reviewer: Advancing code review automation with large language models through parameter-efﬁcient ﬁne- tuning,

J. Lu, L. Y u, X. Li, L. Y ang, and C. Zuo, “LLaMA- Reviewer: Advancing code review automation with large language models through parameter-efﬁcient ﬁne- tuning,” in 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE) , 2023, pp. 647– 658

2023
[10]

Debugging with open-source large language models: An evaluation,

Y . Majdoub and E. Ben Charrada, “Debugging with open-source large language models: An evaluation,” in Proceedings of the 18th ACM/IEEE International Sym- posium on Empirical Software Engineering and Measure- ment, ser. ESEM ’24. New Y ork, NY , USA: Association for Computing ...

2024
[11]

Methods2Test: A dataset of focal methods mapped to test cases,

M. Tufano, S. K. Deng, N. Sundaresan, and A. Svy- atkovskiy, “Methods2Test: A dataset of focal methods mapped to test cases,” in Proceedings of the 19th Inter- national Conference on Mining Software Repositories , 2022, pp. 299–303

2022
[12]

TIOBE index for November 2024,

TIOBE Software BV, “TIOBE index for November 2024,” https://www.tiobe.com/tiobe-index/, Nov 2024

2024
[13]

Octoverse: AI leads Python to top language as the number of global developers surges,

G. Staff, “Octoverse: AI leads Python to top language as the number of global developers surges,” https://github.blog/news-insights/octoverse/octoverse-2024/, 2024

2024
[14]

pyMeth- ods2Test: A dataset of Python tests mapped to focal methods,

I. Abdelmadjid and R. Dyer, “pyMeth- ods2Test: A dataset of Python tests mapped to focal methods,” 2024. [Online]. Available: https://doi.org/10.5281/zenodo.14264518

2024 doi
[15]

Boa: A language and infrastructure for analyzing ultra- large-scale software repositories,

R. Dyer, H. A. Nguyen, H. Rajan, and T. N. Nguyen, “Boa: A language and infrastructure for analyzing ultra- large-scale software repositories,” in Proceedings of the 35th International Conference on Software Engineering , ser. ICSE’13, 2013, pp. 422–431

2013
[16]

Unit test case generation with transform- ers and focal context,

M. Tufano, D. Drain, A. Svyatkovskiy, S. K. Deng, and N. Sundaresan, “Unit test case generation with transform- ers and focal context,” arXiv preprint arXiv:2009.05617 , 2020

2009 arXiv
[17]

Testroutes: A manually curated method level dataset for test-to-code traceability,

A. Kicsi, L. Vid´ acs, and T. Gyim´ othy, “Testroutes: A manually curated method level dataset for test-to-code traceability,” in Proceedings of the 17th International Conference on Mining Software Repositories , 2020, pp. 593–597

2020
[18]

PyCQA, “PyLint,” 2024, available online: https://pylint.pycqa.org

2024
[19]

Bandit: A tool to ﬁnd common secu- rity issues in Python code,

OpenStack, “Bandit: A tool to ﬁnd common secu- rity issues in Python code,” 2024, available online: https://bandit.readthedocs.io

2024
[20]

Defects4J: a databa se of existing faults to enable controlled testing studies for Java programs,

R. Just, D. Jalali, and M. D. Ernst, “Defects4J: a databa se of existing faults to enable controlled testing studies for Java programs,” in Proceedings of the 2014 International Symposium on Software T esting and Analysis, ser. ISSTA

2014
[21]

When do changes induce ﬁxes?

J. ´Sliwerski, T. Zimmermann, and A. Zeller, “When do changes induce ﬁxes?” in Proceedings of the 2005 Inter- national W orkshop on Mining Software Repositories , ser. MSR. New Y ork, NY , USA: Association for Computing Machinery, 2005, p. 1–5

2005
[22]

A3test: Assertion-augmented automated test case gen- eration,

S. Alagarsamy, C. Tantithamthavorn, and A. Aleti, “A3test: Assertion-augmented automated test case gen- eration,” Information and Software T echnology, vol. 176, p. 107565, 2024

2024
[2014]

New Y ork, NY , USA: Association for Computing Machinery, 2014, p. 437–440

2014

Pith tools

Reviewed August 8, 2026 · model on record in the stance chip above.

[1] [1]

A survey on unit testing prac- tices and problems,

E. Daka and G. Fraser, “A survey on unit testing prac- tices and problems,” in 2014 IEEE 25th International Symposium on Software Reliability Engineering , 2014, pp. 201–211

work page 2014

[2] [2]

Refactoring test code,

A. Deursen, L. M. Moonen, A. Bergh, and G. Kok, “Refactoring test code,” CWI (Centre for Mathematics and Computer Science), NLD, Tech. Rep., 2001

work page 2001

[3] [3]

Understanding myths and realities of test-suite evolution,

L. S. Pinto, S. Sinha, and A. Orso, “Understanding myths and realities of test-suite evolution,” in Proceedings of the ACM SIGSOFT 20th International Symposium on the F oundations of Software Engineering, ser. FSE ’12. New Y ork, NY , USA: Association for Computing Machinery, 2012

work page 2012

[4] [4]

Evosuite: automatic test suite generation for object-oriented software,

G. Fraser and A. Arcuri, “Evosuite: automatic test suite generation for object-oriented software,” in Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on F oundations of Software Engi- neering, ser. ESEC/FSE ’11. New Y ork, NY , USA: As- sociation for Computing Machinery, 2011, p. 416–419

work page 2011

[5] [5]

Randoop: feedback- directed random testing for Java,

C. Pacheco and M. D. Ernst, “Randoop: feedback- directed random testing for Java,” in Companion to the 22nd ACM SIGPLAN Conference on Object-Oriented Programming Systems and Applications Companion , ser. OOPSLA ’07. New Y ork, NY , USA: Association for Computing Machinery, 2007, p. 815–816

work page 2007

[6] [6]

Whole test suite generation,

G. Fraser and A. Arcuri, “Whole test suite generation,” IEEE Transactions on Software Engineering , vol. 39, no. 2, pp. 276–291, 2013

work page 2013

[7] [7]

A comparative analysis of large language models for code documentation generation,

S. S. Dvivedi, V . Vijay, S. L. R. Pujari, S. Lodh, and D. Kumar, “A comparative analysis of large language models for code documentation generation,” in Proceed- ings of the 1st ACM International Conference on AI- Powered Software, ser. AIware 2024. New Y ork, NY , USA: Association for Computing Machinery, 2024, p. 65–73

work page 2024

[8] [8]

Chatunitest: A framework for llm-based test gener- ation,

Y . Chen, Z. Hu, C. Zhi, J. Han, S. Deng, and J. Yin, “Chatunitest: A framework for llm-based test gener- ation,” in Companion Proceedings of the 32nd ACM International Conference on the F oundations of Software Engineering, ser. FSE 2024. New Y ork, NY , USA: As- sociation for Computing Machinery, 2024, p. 572–576

work page 2024