Teralizer: Semantics-Based Test Generalization

• Teralizer is a semantics-based framework that automatically converts conventional JUnit tests into property-based jqwik tests through white-box symbolic analysis.
• It extracts precise preconditions and postconditions from symbolic execution, enabling systematic test generalization and improving mutation scores by up to 4 percentage points.
• The framework integrates with standard Java build tools and has been empirically evaluated on diverse projects, highlighting both its potential and current limitations in type support and static analysis.

Teralizer is a semantics-based test generalization framework that automatically transforms conventional example-based JUnit unit tests into property-based jqwik tests for Java. Unlike prior approaches that generalize from input-output examples alone, Teralizer performs white-box single-path symbolic analysis on both the test and its associated implementation, extracting precise precondition and postcondition specifications from program semantics. This enables systematic generation of property-based tests without manual property definition, facilitating broader property-based testing (PBT) adoption and improving test suite effectiveness, especially in domains amenable to symbolic analysis (Glock et al., 16 Dec 2025).

1. Motivation and Problem Definition

Conventional unit tests exercise and check individual input-output pairs within the codebase but leave the remainder of the execution space unvalidated. This introduces a fundamental coverage gap: a mutant or regression that preserves the behavior at the tested input(s) but violates general program rules will evade detection. Property-based testing frameworks address this limitation by generating multiple inputs under developer-specified properties, but adoption barriers include the need for manual property formulation and generator specification.

Teralizer aims to bridge this gap by leveraging white-box symbolic analysis to generalize existing unit tests automatically. The framework extracts the exact path constraints (preconditions $\Phi(\mathbf{x})$) and symbolic expected outputs (postconditions $\psi(\mathbf{x})$) traversed during the original test, effectively lifting concrete assertions to universally quantified properties over the input space traversed by that specific execution path.

2. Algorithmic Pipeline and Symbolic Analysis

Teralizer implements a five-stage pipeline for test generalization:

1. Test & Assertion Analysis: Scans JUnit test methods and their assertions.
2. Tested Method Identification: Determines the method under test (MUT) and its invocation context.
3. Specification Extraction: Performs single-path symbolic execution, using Symbolic PathFinder (SPF) to collect the symbolic path constraints and symbolic output expressions for the specific execution path covered by each test.
4. Generalized Test Creation: Converts the extracted specification into jqwik property-based tests, generating appropriate generators and oracles based on the path constraints and symbolic output.
5. Mutation-based Test Reduction: Applies mutation testing (via PIT) to prune redundant property-based tests and optimize suite effectiveness.

Given a MUT $m : \tau_1 \times \dots \times \tau_n \to \tau_r$ and a corresponding JUnit test executing $m(\mathbf{v})$ and asserting $\texttt{assertEquals}(E, R)$, Teralizer:

• Wraps the MUT invocation.
• Executes SPF in constraint-collection mode, extracting:
  • The path constraint $\Phi(\mathbf{x})$, a conjunction of linear integer/boolean conditions over symbolic input variables.
  • The symbolic output $\psi(\mathbf{x})$, a symbolic expression for the return value.
• Example snippet (for a method involving conditional branches):

int calculate(int sales, int target) { if (sales/2 >= target) return sales/10; else if (sales >= target) return sales/20; return 0; }

For the test sales=1500, target=1000 that enters the "good" branch, SPF produces:

• $\Phi(s, t) = (s/2 < t) \wedge (s \geq t)$
• $\psi(s, t) = s/20$

The extracted specifications are serialized as JSON, recording the path, precondition, and symbolic output.

3. Property-Based Test Synthesis

The property-based jqwik test is constructed by:

• Annotating with @Property(supplier=..., tries=N).
• Defining a parameter holder class reflecting the MUT's input types (e.g., int sales, int target).
• Replacing the concrete test inputs with symbolic parameters sourced from generators.
• Encoding the path constraint $\Phi$ either as a generator restriction or a .filter(...) clause (Improved vs. Naive strategies).
• Encoding the symbolic postcondition $\psi$ as an oracle computing the expected value for comparison.

A canonical jqwik fragment:

@Property(supplier=ImprovedSupplier.class, tries=200) void testCalculate(TestParams _p_) { BonusCalculator c = new BonusCalculator(); int actual = c.calculate(_p_.sales, _p_.target); assertEquals(calculateExpected(_p_), actual); } int calculateExpected(TestParams _p_) { return _p_.sales / 20; }

The property asserts:

$$\forall \mathbf{x}~.~\Phi(\mathbf{x}) \implies m(\mathbf{x}) = \psi(\mathbf{x})$$

ensuring that, for all inputs along the tested execution path, the property holds.

4. Implementation Characteristics and Limitations

Teralizer targets Java projects (Java 5–8) and is compatible with Maven/Gradle builds. It supports JUnit 4/5 (original) and jqwik (generated) tests. The implementation integrates:

• Spoon: For parsing, call-graph analysis, and assertion extraction.
• Symbolic PathFinder (SPF): For single-path symbolic execution.
• PIT/JaCoCo: For mutation testing and code coverage.

Current limitations include:

• Type Support: Only supports primitives (int, boolean). No string, object, array, or floating-point analysis.
• Static Analysis: Only intraprocedural; cannot analyze assertions in helper methods or handle loops.
• Test Types: Only standard @Test methods; lacks support for JUnit3, parameterized, repeated, or TestNG tests.
• Project Layout: Expects standard output directory layouts for integration with build tools and mutation testing frameworks.

5. Empirical Evaluation and Effectiveness

The evaluation spans three strata:

• EqBench + EvoSuite: 652 numeric-only classes, with tests generated by EvoSuite at various resource budgets.
• Apache Commons Utilities: 247 classes, including both evolutionary tests and 725 developer-written tests.
• RepoReapers Real-World Projects: 632 curated Java projects with robust engineering practices.

Key results:

Dataset/Condition	Baseline Mutation (%)	Teralizer Mutation (%)	Absolute Δ (%)	Relative Δ (%)
EqBench+EvoSuite	48–52	52–55	+1–4	+2–8
Commons-utils+EvoSuite	57–58	58–59	+0.8–1.3	–
Commons-utils-developer	80.35	80.40–80.42	+0.05–0.07	–

• On numeric and EvoSuite-generated tests, Teralizer improves mutation score by 1–4 percentage points, demonstrating substantive test suite enhancement.
• For mature, developer-written suites, improvement is marginal (0.05–0.07 pp), suggesting limited additional value in highly optimized testing contexts.
• Efficiency analysis indicates that EvoSuite (1 s) combined with Teralizer (tries=50) exceeds the detection rate of EvoSuite alone run at 60 s, at a lower total cost.

Applicability in the wild remains sharply constrained: only 1.7% (11/632) of real-world projects completed the full pipeline. The overwhelming majority of assertions are filtered due to unsupported data types or assertion patterns. Remaining failures arise from unsuitable tests, nonstandard layouts, timeouts in symbolic execution or mutation analysis, and integration artifacts.

6. Barriers, Research Challenges, and Future Roadmap

Barriers to adoption are both technical and infrastructural:

• Type limitations necessitate extension of symbolic engines to handle strings, arrays, objects, and non-linear constraints (e.g., via Z3-Noodler, OSTRICH2, or JBSE).
• Static analysis would benefit from interprocedural capability to capture assertions in helper methods, loop unrolling, and recursive test handling.
• Constraint-aware generation presents open questions: balancing boundary vs. random inputs, incremental test amplification, and possible SMT-guided strategies.
• Infrastructure needs to accommodate diverse build systems, project organization heuristics, and tunable timeouts for end-to-end automation.
• Usability challenges include delivering readable, explainable generated properties and facilitating developer understanding and editing.

An open replication package provides full source code, artifacts, and evaluation data for further research (Glock et al., 16 Dec 2025).

7. Significance and Outlook

Teralizer establishes a tractable semantics-based approach to unit-to-property-based test generalization via single-path symbolic analysis, demonstrating modest yet tangible improvements in controlled experimental settings. The main bottleneck for broader impact is symbolic execution's limited expressivity for common programming types and patterns. Addressing these challenges will require advances in symbolic reasoning, test analysis infrastructure, and integration with development workflows. The results delineate a roadmap for augmenting both the automation and the reach of property-based testing in large software systems.