Unit Test Generation Data: Focal Code, Tests and Coverage from Real Projects

What a usable focal-test record contains

A usable record links one test to one focal unit, states how that link was derived, and carries measured quality signals rather than just source text. Public research datasets show the range: UniTSyn collected 2.7 million focal-test pairs across five languages by resolving calls through the Language Server Protocol [1], while Go-UT-Bench is far smaller at 5,264 Go pairs but records the repository, file paths and commit hash for each entry [2]. For a commercial dataset, ask for both scale and that level of provenance.

The minimum fields are the focal method signature and body, the enclosing class or module context, the test method, test-file imports and setup (@BeforeEach, setUp, pytest fixtures, TestMain), the build target, and the commit SHA where both existed together. Add coverage, mutation and flakiness fields, described below, and you have a record that can serve as both an SFT target and a reward signal.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "record_id": "utg-000412",
  "repo_alias": "repo_17",
  "commit_sha": "9f3c2e1",
  "language": "java",
  "build_system": "gradle",
  "focal": {
    "path": "billing/src/main/java/InvoiceCalculator.java",
    "signature": "BigDecimal applyDiscount(Invoice inv, DiscountRule rule)",
    "class_context_tokens": 1840
  },
  "test": {
    "path": "billing/src/test/java/InvoiceCalculatorTest.java",
    "method": "appliesTieredDiscountAboveThreshold",
    "framework": "junit5",
    "mocks": ["mockito", "internal:FakeLedgerClient"]
  },
  "mapping": { "method": "coverage", "confidence": 0.93, "also_matched_by": ["naming"] },
  "coverage": { "focal_line_pct": 88.0, "focal_branch_pct": 75.0, "tool": "jacoco" },
  "mutation": { "tool": "pitest", "killed": 14, "survived": 3, "no_coverage": 1 },
  "stability": { "reruns": 20, "failures": 0, "uses_network": false, "uses_wall_clock": false },
  "fixture_deid": { "method": "pseudonymized", "fields": ["customer_name", "email", "account_no"] }
}

How the focal mapping was derived matters

The mapping method determines label noise, so require suppliers to report it per record. Three methods are common: naming conventions (FooTest.testBar maps to Foo.bar), static call-graph or LSP resolution from the test body [1], and dynamic mapping from per-test coverage, which records what the test actually executed. Naming is cheap but breaks on helper-heavy suites; call graphs miss reflection and dependency injection; coverage-based mapping is the most faithful but requires a working build.

Noise is not a theoretical concern. A data-quality study of Methods2Test (about 781,000 pairs) and Atlas (about 188,000 pairs) found that noisy focal-test data degrades test-generation models, which supports filtering for quality before scaling for volume [3]. When two methods disagree, keep both labels and a confidence value rather than silently picking one.

Coverage and mutation scores turn tests into ranked targets

Per-test coverage and mutation results let you train on strong tests and use weak ones only as negatives. Line coverage alone rewards tests that execute code without checking it; mutation testing (PIT for Java, Stryker for JavaScript and C#, mutmut for Python, go-mutesting for Go) measures whether assertions actually catch injected faults. Ask for killed, survived and no-coverage counts per test, not a project-level percentage.

Coverage should be per test, scoped to the focal unit, and produced by a named tool and version (JaCoCo, coverage.py, Istanbul/nyc, go test -coverprofile, gcov/llvm-cov). A suite-level LCOV or Cobertura report cannot tell you which test covered which branch. If a supplier can only provide suite-level coverage, treat the dataset as unranked and budget for re-running tests yourself.

These signals also make good reward functions for RL or rejection sampling: compile success, pass on the original code, focal coverage gain and mutants killed. That only works if the dataset ships enough build context to execute tests, which overlaps with the environment requirements in SWE task environments with tests.

Flaky and environment-dependent tests poison both training and evaluation

Flag flaky tests before training, because a model that learns from them learns to write nondeterministic tests. Ask for rerun counts and failure counts per test, and for flags on tests that touch the network, wall-clock time, random seeds without fixing them, the filesystem, ordering of hash maps, or shared state between tests. OpenAI's write-up on SWE-bench Verified named overly specific unit tests and unreliable development-environment setup among the problems it found in the original benchmark [5].

Quarantined tests (@Disabled, @pytest.mark.skip, t.Skip(), CI retry annotations) are useful signal: keep them with their status rather than dropping them. They can serve as negative examples or as a held-out flakiness-detection task.

Fixtures, mocks and the enterprise gap

Enterprise test suites contain what public data lacks: internal mocking frameworks, service stubs, contract-test fakes, golden files and seeded databases that reflect how a company actually isolates dependencies. Ask suppliers to include these helper modules and the test-utility packages they import, or your model will learn to call fakes it has never seen. This is the main reason to license private code instead of relying on mined open-source pairs; see open code datasets vs licensed private code.

Fixtures are also where real customer data hides. JSON fixtures, SQL seed scripts, VCR or WireMock cassettes and snapshot files are often copied from production. Require the same de-identification standard for test data as for any record: replace names, emails, phone numbers and account numbers, record the method, and check a sample.

If fixtures hold protected health information from a HIPAA covered entity or business associate, de-identify them via Safe Harbor or Expert Determination [8]. Credentials in fixtures and CI config are a separate problem covered in secrets removal for code datasets.

Buyer checklist for a unit test generation dataset

Use this checklist when writing a request or reviewing a sample. It complements the broader code dataset request specification.

Illustrative example: invented to show structure; it does not describe an available dataset.

Contamination, duplication and synthetic test data

Deduplicate before splitting, because copied test helpers and generated tests create near-duplicates that inflate evaluation scores. Near-duplicate examples are common in training corpora and increase verbatim memorization [7]; in test suites this shows up as vendored test utilities, parameterized tests expanded into many files and snapshot tests. Split by repository, not by record, so a held-out evaluation does not share a codebase with training. See deduplicating code training data.

Public benchmarks lose value once they leak into training: OpenAI stopped reporting SWE-bench Verified in 2026, citing contamination [6]. Private enterprise tests are less exposed, but check for public forks and mirrors using the approach in code benchmark contamination. Synthetic generation is an active alternative, including file-level test data synthesized with chain-of-thought and self-debugging [4]; the trade-offs are covered in synthetic vs licensed code data.

How SourceX sources unit test data

SourceX sources operational datasets, including engineering records, from US companies on request; nothing is held in stock and a request does not guarantee a match. You describe the data you need, such as Java services with JUnit 5 suites and per-test coverage, and SourceX looks for US businesses that hold it. Each dataset is rights-reviewed for ownership and consents, personal details in records are removed or replaced with the method recorded and a sample checked, and delivery runs through private, access-controlled workflows only after an executed agreement and supplier approval.

Related owner pages cover proprietary codebases with full git history and software engineering histories from private repos; the code data buyer's map and the AI data hub cover adjacent needs. You can describe your test-generation data needs at any point.

Request unit test generation data

SourceX sources engineering records from US companies on request and manages licensing, with every release approved by the supplying company. Every dataset is rights-reviewed and delivered under a license that defines records, uses, term and delivery. Describe the focal-test data you need on the SourceX buyers page.