Identifying Patch Correctness in Test-Based Program Repair

TL;DR

This paper introduces a heuristic method that uses behavior similarity of test executions to identify correct patches in test-based program repair, significantly reducing incorrect patches.

Contribution

The paper presents a novel approach leveraging test behavior similarity and input generation to improve correctness verification in automatic program repair.

Findings

Prevented 56.3% of incorrect patches

Did not block any correct patches

Effective across multiple repair systems

Abstract

Test-based automatic program repair has attracted a lot of attention in recent years. However, the test suites in practice are often too weak to guarantee correctness and existing approaches often generate a large number of incorrect patches. To reduce the number of incorrect patches generated, we propose a novel approach that heuristically determines the correctness of the generated patches. The core idea is to exploit the behavior similarity of test case executions. The passing tests on original and patched programs are likely to behave similarly while the failing tests on original and patched programs are likely to behave differently. Also, if two tests exhibit similar runtime behavior, the two tests are likely to have the same test results. Based on these observations, we generate new test inputs to enhance the test suites and use their behavior similarity to determine patch correctness. Our approach is evaluated on a dataset consisting of 139 patches generated from existing program repair systems including jGenProg, Nopol, jKali, ACS and HDRepair. Our approach successfully prevented 56.3\% of the incorrect patches to be generated, without blocking any correct patches.

Tables

Table 1. Table 1. Dataset

Project	jGenprog			jKali			Nopol2015			Nopol2017			ACS			HDRepair			Total(Generated)			Developer Patches
	P	C	I	P	C	I	P	C	I	P	C	I	P	C	I	P	C	I	P	C	I	P	C	I
Chart	6	0	6	6	0	6	6	1	5	6	0	6	2	2	0	0	0	0	26	3	23	25	25	0
Lang	0	0	0	0	0	0	7	3	4	4	0	4	3	1	2	1	0	1	15	4	11	58	58	0
Math	14	5	9	10	1	9	15	1	14	22	0	22	15	11	4	7	2	5	83	20	63	84	84	0
Time	2	0	2	2	0	2	1	0	1	8	0	8	1	1	0	1	1	0	15	2	13	27	27	0
Total	22	5	17	18	1	17	29	5	24	40	0	40	21	15	6	9	3	6	139	29	110	194	194	0

Table 2. Table 2. Different syntactic and semantic metrics

Metric	Type	Scope	Description
AST-based (Mechtaev et al., 2015; Le et al., 2017)	Syn	General	Number of AST node changes introduced by the patch.
Cosine similarity (Le et al., 2017)	Syn	Replacement	The cosine similarity between the vectors representing AST node occurrences before and after the change. It is not clear how to apply it to insertions and deletions because there will be a zero vector and cosine similarity cannot be calculated.
Locality of variables and constants (Le et al., 2017)	Syn	Expression Replacement	The distance is measured by the Hamming distance between the vectors representing locations of variables and constants. It is not clear how to apply it to patches with multiple changes.
Expression size distance (D’Antoni et al., 2016)	Syn	Expression Replacement	The distance is 0 when two expressions are identical, otherwise the size of the affected expression after patching. It is not clear how to apply it to changes other than expression replacement.
Complete-path spectrum (D’Antoni et al., 2016)	Sem	General	The difference between complete-path spectra.
Model counting (Le et al., 2017)	Sem	Boolean Expression replacement	The distance is measured by the number of models that make two expressions evaluate differently. The definition is bounded to Boolean expressions.
Output coverage (Le et al., 2017)	Sem	Programs with simple outputs	The distance is measured by the proportion of different outputs covered by the patched program. It is not clear how to define “output” in general for complex programs.

Table 3. Table 3. PATCH-SIM

	Passing Tests	Failing Tests
Incorrect Patches	0.25	0.33
Correct Patches	0.02	0.19

Table 4. Table 4. Overall Effectiveness per Tool

Tool	Incorrect	Correct	Incorrect Excluded	Correct Excluded
jGenprog	17	5	8(47.1%)	0
jKali	17	1	9(52.9%)	0
Nopol2015	24	5	16(66.7%)	0
Nopol2017	40	0	22(55.0%)	0
ACS	6	15	3(50.0%)	0
HDRepair	6	3	4(66.7%)	0
Total	110	29	62(56.3%)	0

Table 5. Table 5. Overall Effectiveness per Project

Project	Incorrect	Correct	Incorrect Excluded	Correct Excluded
Chart	23	3	14(60.9%)	0
Lang	11	4	6(54.5%)	0
Math	63	20	33(52.4%)	0
Time	13	2	9(69.2%)	0
Total	110	29	62(56.3%)	0

Table 6. Table 6. Comparison with no test generation

	Default Approach	No Generation
Incorrect Excluded	62	54
Correct Excluded	0	0

Table 7. Table 7. Parameter K p subscript 𝐾 𝑝 K_{p}

	0.05	0.1	0.15	0.25	0.3	0.4	0.5	0.6	0.8	1
IE	71	66	62	62	60	57	56	56	55	54
CE	4	1	0	0	0	0	0	0	0	0

Table 8. Table 8. Parameter K t subscript 𝐾 𝑡 K_{t}

	0	0.1	0.2	0.3	0.4	0.5	0.6	0.7	0.8	0.9	1
IE	65	62	62	62	62	60	60	60	60	59	59
CE	4	1	0	0	0	0	0	0	0	0	0

Equations

$$distance(a,b)=1-\frac{|LCS(a,b)|}{max(|a|,|b|)}$$

$$\displaystyle{\it classification}(t^{\prime})=\left\{\begin{array}[]{cc}\emph{passing}&\quad A_{p}<A_{f}\\ \emph{failing}&\quad A_{p}>A_{f}\\ \emph{discarded}&\quad A_{p}=A_{f}\end{array}\right.$$

$$A_p=min(\{distance(t,t^{\prime })\mid classification(t)=passing\})$$

$$A_f=min(\{distance(t,t^{\prime })\mid classification(t)=failing\})$$

$$\displaystyle{\it classification}(t)=\left\{\begin{array}[]{cc}\emph{passing}&\quad K_{t}\leq A_{f}\\ \emph{failing}&\quad K_{t}>A_{f}\\ \end{array}\right.$$

$$A_f=min(\{distance(t,t^{\prime })\mid classification(t^{\prime })=failing\})$$

$$\displaystyle{\it classification}(p)=\left\{\begin{array}[]{cc}\emph{incorrect}&A_{p}\geq K_{p}\\ \emph{incorrect}&A_{p}\geq A_{f}\\ \emph{correct}&\mathrm{otherwise}\\ \end{array}\right.$$

$$A_p=max(\{distanc{e}_p(t)\mid classification(t)=passing\})$$

$$A_f=mean(\{distanc{e}_p(t)\mid classification(t)=failing\})$$

$$LED(p)=mean(\{distanc{e}_p(t)\mid t\in T_o\})$$

Full text

To reduce the number of incorrect patches generated, we propose a novel approach that heuristically determines the correctness of the generated patches. The core idea is to exploit the behavior similarity of test case executions. The passing tests on original and patched programs are likely to behave similarly while the failing tests on original and patched programs are likely to behave differently. Also, if two tests exhibit similar runtime behavior, the two tests are likely to have the same test results. Based on these observations, we generate new test inputs to enhance the test suites and use their behavior similarity to determine patch correctness.

Our approach is evaluated on a dataset consisting of 139 patches generated from existing program repair systems including jGenProg, Nopol, jKali, ACS and HDRepair. Our approach successfully prevented 56.3% of the incorrect patches to be generated, without blocking any correct patches.

The authors acknowledge the anonymous reviewers for the constructive comments and revision suggestions. This work is supported by the National Key Research and Development Program under Grant No. 2016YFB1000105, and National Natural Science Foundation of China under Grant No. 61725201, 61529201, 61725201, 61672045. Lu Zhang is the corresponding author. Xinyuan Liu and Muhan Zeng are equal contributors to the paper and their names are sorted alphabetically.

††journalyear: 2018††copyright: acmcopyright††conference: ICSE ’18: 40th International Conference on Software Engineering ; May 27-June 3, 2018; Gothenburg, Sweden††booktitle: ICSE ’18: ICSE ’18: 40th International Conference on Software Engineering , May 27-June 3, 2018, Gothenburg, Sweden††price: 15.00††doi: 10.1145/3180155.3180182††isbn: 978-1-4503-5638-1/18/05

1. Introduction

In the past decades, a large number of automated program repair approaches (Le Goues et al., 2012b; Xiong et al., 2017; Gao et al., 2015b; Kim et al., 2013; Long and Rinard, 2015; Le et al., 2016; Gupta et al., 2017; Long and Rinard, 2016a; Gao et al., 2015a; Mechtaev et al., 2016; Nguyen et al., 2013; Mechtaev et al., 2015; Xiong et al., 2015; Liu and Zhong, 2018) have been proposed, and many of them fall into the category of test-based program repair. In test-based program repair, the repair tool takes a faulty program and a test suite including at least one failing test that reveals the fault as input and then generates a patch that makes all tests pass. However, test suites in real world projects are often weak (Qi et al., 2015), and a patched program passing all the tests may still be faulty. We call a patch plausible if the patched version passes all tests in the test suite, and we consider a patch correct if it fixes and only fixes the bug. As studied by Long et al. (Long and Rinard, 2016b), the test suites in real world systems are usually weak such that most of the plausible patches are incorrect, making it difficult for a test-based program repair system to ensure the correctness of the patches. As existing studies (Qi et al., 2015; Smith et al., 2015; Martinez and Monperrus, 2016) show, multiple automatic program repair systems produce much more incorrect patches than correct patches on real world defects, leading to low precision in their generated patches.

The low precision of existing program repair systems significantly affects the usability of these systems. Since test suites cannot guarantee the correctness of the patches, developers have to manually verify patches. When the precision of a program repair system is low, the developer has to verify a lot of incorrect patches, and it is not clear whether such a verification process is more costly than directly repairing the defect by the developers. An existing study (Tao et al., 2014) also shows that, when developers are provided with low-quality patches, their performance will drop compared to the situation where no patch is provided. As a result, we believe it is critical to improve the precision of program repair systems, even at the risk of losing some correct patches.

Since a weak test suite is not enough to filter out the incorrect patches produced by program repair systems, a direct idea is to enhance the test suite. Indeed, existing studies (Xin and Reiss, 2017; Yang et al., 2017) have attempted to generate new test cases to identify incorrect patches. However, while test inputs can be generated, test oracles cannot be automatically generated in general, known as the oracle problem  (Barr et al., 2015; Pezze and Zhang, 2015). As a result, existing approaches either require human to determine test results (Xin and Reiss, 2017), which is too expensive in many scenarios, or rely on inherent oracles such as crash-free (Yang et al., 2017), which can only identify certain types of incorrect patches that violate such oracles.

Our goal is to classify patches heuristically without knowing the full oracle. Given a set of plausible patches, we try to determine whether each patch is likely to be correct or incorrect, and reject the patches that are likely to be incorrect. Our approach is based on two key observations.

• •

PATCH-SIM. After a correct patch is applied, a passing test usually behaves similarly as before, while a failing test usually behaves differently.

• •

TEST-SIM. When two tests have similar executions, they are likely to have the same test results, i.e., both triggering the same fault or both are normal executions.

PATCH-SIM allows us to test patches without oracles, i.e., we run the tests before and after patching the system and check the degree of behavior change. As our evaluation will show later, PATCH-SIM alone already identify a large set of incorrect patches. However, we can only utilize the original tests but not the newly generated test inputs as we do not know whether they pass or fail. TEST-SIM allows us to use newly generated test inputs: if a generated test input behaves similarly to an original passing test, it is likely to be a passing test. Similarly, if it behaves similarly to a failing test, it is likely to be a failing test.

Please note that TEST-SIM does not solve the oracle problem: a test classified as failing is unlikely to expose new faults. Nevertheless, TEST-SIM is useful in complementing PATCH-SIM for patch classification.

Based on these two key observations, our approach consists of the following steps. First, we generate a set of new test inputs. Second, we classify the newly generated test inputs as passing or failing tests by comparing them with existing test inputs. Third, we determine the correctness of the patch by comparing the executions before and after the patch for each test, including both the original and the generated tests.

We have realized our approach by designing concrete formulas to compare executions, and evaluated our approach on a dataset of 139 patches generated from previous program repair systems including jGenProg (Martinez and Monperrus, 2016), Nopol (Martinez and Monperrus, 2016), jKali (Martinez and Monperrus, 2016), HDRepair (Le et al., 2016), and ACS (Xiong et al., 2017). Our approach successfully filtered out 56.3% of the incorrect patches without losing any of the correct patches. The results indicate that our approach increases the precision of program repair approaches with limited negative impact on the recall.

In summary, the paper makes the following main contributions.

• •

We propose two heuristics, PATCH-SIM and TEST-SIM, which provide indicators for patch correctness.

• •

We design a concrete approach that automatically classifies patches based on the two heuristics.

• •

We have evaluated the approach on a large set of patches, and the results indicate the usefulness of our approach.

The rest of the paper is organized as follows. Section 2 first discusses related work. Section 3 motivates our approach with examples, and Section 4 introduces our approach in details. Section 5 introduces our implementation. Section 6 describes our evaluation on the dataset of 139 patches. Section 7 discusses the threats to validity. Finally, Section 8 concludes the paper.

2. Related Work

**Test-based Program Repair. ** Test-based program repair is often treated as a search problem by defining a search space of patches, usually through a set of predefined repair templates, where the goal is to locate correct patches in the search space. Typical ways to locate a patch include the follows.

• •

Search Algorithms. Some approaches use meta-heuristic (Le Goues et al., 2012b; Long and Rinard, 2015) or random (Qi et al., 2014) search to locate a patch.

• •

Statistics. Some approaches build a statistical model to select the patches that are likely to fix the defects based on various information sources, such as existing patches (Kim et al., 2013; Long and Rinard, 2016a; Le et al., 2016) and existing source code (Xiong et al., 2017).

• •

Constraint Solving. Some approaches (Nguyen et al., 2013; Mechtaev et al., 2015, 2016; D’Antoni et al., 2016; Singh et al., 2013; Le et al., 2017) convert the search problem to a satisfiability or optimization problem and use constraint solvers to locate a patch.

While the concrete methods for generating patches are different, weak test suites problem still remains as a challenge to test-based program repair and may lead to incorrect patches generated. As our evaluation has shown, our approach can effectively augment these existing approaches to raise their precisions.

**Patch Classification. ** Facing the challenge of weak test suites, several researchers also propose approaches for determining the correctness of patches. Some researchers seek for deterministic approaches. Xin and Reiss (Xin and Reiss, 2017) assume the existence of a perfect oracle (usually manual) to classify test results and generate new test inputs to identify oracle violations. Yang et al. (Yang et al., 2017) generate test inputs and monitor the violation of inherent oracles, including crashes and memory-safety problems. Compared with them, our approach does not need a perfect oracle and can potentially identify incorrect patches that do not violate inherent oracles, but has the risk of misclassifying correct patches.

Other approaches also use heuristic means to classify patches. Tan et al. (Tan et al., 2016) propose anti-patterns to capture typical incorrect patches that fall into specific static structures. Our approach mainly relies on dynamic information, and as the evaluation will show, the two approaches can potentially be combined. Yu et al. (Yu et al., 2017) study the approach that filters patches by minimizing the behavioral impact on the generated tests, and find that this approach cannot increase the precision of existing program repair approaches. Compared with their approach, our approach classifies the generated tests and puts different behavioral requirements on different classes. Finally, Weimer et al. (Weimer et al., 2016) highlight possible directions in identifying the correctness of patches.

**Patch Ranking. ** Many repair approaches use an internal ranking component that ranks the patches by their probability of being correct. Patch ranking is a very related but different problem from patch classification. On the one hand, we can convert a patch classification problem into a patch ranking problem by setting a proper threshold to distinguish correct and incorrect patches. On the other hand, a perfect patch ranking method does not necessarily lead to a perfect patch classification method, as the threshold can be different from defect to defect.

There are three main categories of patch ranking techniques. The first ranks patches by the the number of passing tests. However, this category cannot rank plausible patches. The second category uses syntactic (Mechtaev et al., 2015; D’Antoni et al., 2016; Le et al., 2017) and semantic distances (D’Antoni et al., 2016; Le et al., 2017) from the original program to rank patches. As our evaluation will show later, our approach could significantly outperform both types of distances. The third category (Long and Rinard, 2016a; Le et al., 2016; Xiong et al., 2017) learns a probabilistic model from existing rules to rank the patches. Our approach could complement these approaches: as our evaluation will show later, our approach is able to identify 50% of the incorrect patches generated by ACS, the newest approach in this category.

**Approaches to the Oracle Problem. ** The lack of test oracle is a long-standing problem in software testing, and the summaries of the studies on this problem can be found in existing surveys (Barr et al., 2015; Pezze and Zhang, 2015).

Among them, many studies focus on automatically generating test oracles, by mining invariants at important programming points (Ernst et al., 2001; Ernst et al., 2007), discovering important variables by mutation analysis (Fraser and Zeller, 2012), or using machine-learning algorithms to classify test runs (Haran et al., 2005; Baah et al., 2006). However, most of such approaches assume a correct version of the program already exists, which does not apply to the scenario of patch correctness identification since the original program is already incorrect. On the other hand, some approaches do not require a full version of the correct program and have the potential to be applied on patch classification.

For example, invariant mining could potentially mine invariants (Ernst et al., 2001; Ernst et al., 2007) from passing test executions to classify new test inputs. However, the effect of such an application on patch correctness identification is still unknown as far as we are aware and remains as future work.

**Other related work. ** Marinescu and Cadar (Marinescu and Cadar, 2013) propose KATCH for testing patches. KATCH uses symbolic execution to generate test inputs that are able to cover the patched code. Our approach could be potentially combined with KATCH to improve the quality of the generated tests. This is a future direction to be explored.

Several researchers have used independent test suites (Smith et al., 2015; Ke et al., 2015) or using human developers (Qi et al., 2015) to measure the quality of patches produced by program repair approaches. However, these approaches cannot be used to automatically improve the precision of existing program repair approaches, as the independent test suites or human resources are not available.

Several researchers have investigated the use of the generated patches as debugging aids. Weimer (Weimer, 2006) has found that bug reports with generated patches are more likely to be addressed in open source projects. Tao et al. (Tao et al., 2014) further found that the quality of patches is positively correlated to debugging correctness, where high-quality patches have a positive effect on debugging correctness and low-quality patches have a negative effect on debugging correctness. These studies motivate our work.

3. Patch Correctness and Behavior Similarity

In this section, we analyze the relation between patch correctness and behavior similarity to motivate our approach. We define a patch as a pair of program versions, the original buggy version and the patched version. To simplify discussion, we assume the program contains only one fault. As a result, a failing test execution must trigger the fault and produce an incorrect output.

**Weak Oracles and PATCH-SIM. ** As mentioned, a test suite may be weak in either inputs or oracles, or both, to miss such an incorrect patch.

To see how weak oracles could miss an incorrect patch, let us consider the example in Figure 1. Figure 1(a) shows an incorrect patch generated by jKali (Qi et al., 2015) for defect Chart-15 in the defect benchmark Defects4J (Just et al., 2014). In this example, calling draw will result in an undesired exception if the receiver object is initialized with a null dataset. Figure 1(b) shows a test case that detects this defect by creating such an object and checking for exceptions. Figure 1(c) shows a passing test checking that drawing with a null value in the dataset would not result in an exception. This patch simply skips the whole method that may throw the exception.

In both the passing test and the failing test, the oracle only checks that no exception is thrown, but does not check whether the output of the program is correct. As a result, since the patch prevents the exception, both tests pass.

As mentioned in the introduction, we rely on observation PATCH-SIM to validate patches. Given a patch, we would expect that the original program and the patched program behave similarly on a passing test execution, while behaving differently on a failing test execution. In this example, the passing test would draw something on the chart in the original program, but would skip draw method completely in the patched program, leading to significant behavioral difference. Based on this difference, we can determine the patch as incorrect.

**Weak Inputs and TEST-SIM. ** To see how the weak test inputs could lead to the misses of incorrect patches, let us consider the example in Figure 2. This example demonstrates an incorrect patch for Lang-39 in Defects4J produced by Nopol (Xuan et al., 2016). The original program would throw an undesirable exception when an element in replacementList or searchList is null. To prevent such an exception, the correct way is to skip those elements as shown in Figure 2(b). However, the generated patch in Figure 2(a) blocks the whole loop based on the value of repeat, which is a parameter of the method. Interesting, all existing tests, either previously passed or failed, happen to produce the correct outputs in the patched program. This is because (1) the value of repeat happens to be true in all passing tests and be false in all failing tests, and (2) the condition greater>0 is not satisfied by any element in searchList and replacementList in the failing tests. However, enhancing the test oracles by PATCH-SIM is not useful because the behavior on passing tests remains almost the same as the original program while the behavior on failing tests changes a lot.

To capture those incorrect patches missed by weak test inputs, we need new test inputs. To utilize PATCH-SIM with new test inputs, we need to know whether the outputs of the tests are correct or not. To deal with this problem, we utilize observation TEST-SIM. We assume that, when the execution of a new test input is similar to that of a failing test, the new test input is likely to lead to incorrect output. Similarly, when the execution of a new test input is similar to that of a passing test, the new test input is likely to lead to correct output. Based on this assumption, we can classify new test inputs by comparing its execution with those of the existing test inputs.

In the example in Figure 2, for any new test input triggering this bug, there will be an exception thrown in the middle of the loop, which is similar to the executions of failing tests. On the other hand, for any test input that does not trigger this bug, the loop will finish normally, which is similar to the executions of existing passing tests.

**Measuring Execution Similarity. ** An important problem in realizing the approach is how we measure the similarity of two test executions. In our approach, we measure the similarity of complete-path spectrum (Harrold et al., 1998) between the two executions. A complete-path spectrum, or CPS in short, is the sequence of executed statement IDs during a program execution. Several existing studies (Dickinson et al., 2001; Reps et al., 1997; Harrold et al., 1998) show that spectra are useful in distinguishing correct and failing test executions, and Harrold et al. (Harrold et al., 1998) find that CPS is among the overall best performed spectra.

For example, let us consider the two examples in Figure 1 and Figure 2. In both examples, the defect will lead to an exception, which further leads to different spectra of passing and failing tests: the passing tests will execute until the end of the method, while the failing tests will stop in the middle. Furthermore, the failing test executions will become different after the system is patched: no exception will be thrown and the test executes to the end of the method.

**Multiple Faults. ** In the case of multiple faults in a program, the two heuristics still apply. When there are multiple faults, the failing tests may only identify some of them. We simply treat the identified faults as one fault and the rest of them as correct program, and the above discussion still applies.

4. Approach

4.1. Overview

Figure 3 shows the overall process of our approach. We take the original buggy program, a set of test cases, and a patch as input, and produce a classification result that tells whether the patch is correct or not.

Our approach consists of five components classified into three categories: test generation (including test input generator), distance measurement (including test distance measurer and patch distance measurer) and result classification (including test classifier and patch classifier). First, test input generator generates a set of test inputs. We then run the generated tests on the original buggy program. During the test execution, we dynamically collect runtime information about the test execution. Based on the runtime information, test distance measurer calculates the distance between the executions of each newly generated test input and each original test case. A distance is a real number indicating how different two test executions are. The result is a vector of test distances. This vector is then passed to test classifier, which classifies the test as passing or failing by comparing its distances to passing tests and those to failing tests, based on TEST-SIM.

Now we have an enhanced set of test inputs which are classified as passing or failing and we can use them to determine patch correctness. Given a patch, patch distance measurer runs each test on the original program and the patched program and measure the distance between the two executions. The result is a vector of patch distances. Finally, this vector is taken into patch classifier which determines patch correctness by the distances, based on observation PATCH-SIM.

In the rest of this section, we introduce components in the three categories, respectively.

4.2. Test Generation

Given a program, test generator generates test inputs for this program. Furthermore, since our goal is to determine the correctness of the patch, we require the generated tests to cover the patched method. If a patch modifies multiple methods, the generated tests should cover at least one of them.

In theory, any test input generation techniques can be used in our approach. We can utilize symbolic execution techniques to cover the specific method, especially those designed for testing patches (Marinescu and Cadar, 2013). We can also adopt random testing techniques (Pacheco and Ernst, 2007; Fraser and Arcuri, 2011; Ma et al., 2015) and filter out those that do not cover any of the modified methods.

4.3. Distance Measurement

4.3.1. Measuring Distance

As mentioned previously, we measure the distance between two executions by comparing their complete-path spectra. As a result, the problem reduces to measuring the distances between two sequences. In general, there are many different metrics to measure sequence distances, such as longest common subsequence, Levenshtein distance, Hamming distance. As the first attempt in classifying patches based on sequence distances, we use the longest common subsequence (LCS) as a distance measure and leave other distance metrics to future work. An LCS of two sequences $a$ and $b$ is the longest sequence that can be obtained from both $a$ and $b$ by only deleting elements. We then normalize the length of LCS into a value between 0 and 1 using the following formula, where $a$ and $b$ are two sequences.

[TABLE]

4.3.2. Test Distance Measurer

Component test distance measurer takes a generated test and calculates its distance with each original test. The result is a vector of distances, where each element represents a distance between a generated test and an original test.

To focus on the fault, we only consider the executed statements within the calling context of the patched methods. That is, we locate pairs of positions on the runtime trace: (a) entering a patched method from a method call and (b) leaving the method from the same call and keep only the statements between the positions. This step could help us filter noises: two tests may be different in statement executions outside the calling context of the patched methods, but such a difference is often not related to the fault. If an original test does not cover any patched method, we also exclude the test from distance measurement.

4.3.3. Patch Distance Measurer

Component patch distance measurer takes each test, either generated or original and calculates the distance between its executions on the original program and on the patched program. The result is a vector of distances, where each element represents the distance of a test.

Different from test distance measurer, here we consider the full sequence of executed statements. This is because the compared executions come from the same test and they are unlikely to be noises outside the patched method.

4.4. Classification

Based on the distances, we can classify the generated tests and the patches. We describe the two components one by one.

4.4.1. Test Classifier

The test classifier classifies the test result of a generated test as passing or failing. Some generated tests are difficult to precisely classify and we discard these tests. Let $result(t)$ denotes the test result of the original test $t$, i.e., either passing, failing, or discarded. Let $distance(t,t^{\prime})$ denotes the distance between the executions of $t$ and $t^{\prime}$ on the original program. Given a generated test $t^{\prime}$, we use the following formulas to determine its classification result. The formula assigns the result of the nearest-neighbor to the generated test.

[TABLE]

Note that the above formula can only be applied when there is at least a passing test. If there is no passing test, we compare the distances with all failing tests with a threshold $K_{t}$ and deem the test as passing if the test execution is significantly different from all failing tests based on the assumption that the original program works normally on most of the inputs. Please notice that there is always at least one failing test which exposes the defect.

[TABLE]

4.4.2. Patch classifier

The patch classifier classifies a patch as correct or incorrect based on the calculated distances. Let $distance_{p}(t)$ denotes the distance between the executions of test $t$ before and after applying the patch $p$. We determine the correctness of a patch $p$ using the following formula.

[TABLE]

This formula checks the two conditions in observation PATCH-SIM. First, the passing test should behave similarly. To check this condition, we compare the maximum distance on the passing tests with a threshold $K_{p}$ and determine the patch as incorrect if the behavior change is too large. Second, the failing test should behave differently. However, since different defects require different ways to fix, it is hard to set a fixed threshold. As a result, we check whether the average behavior change in failing tests is still larger than all the passing tests. If not, the patch is considered incorrect.

We use the maximum distance for passing tests while using the average distance for failing tests. An incorrect patch may affect only a few passing tests, and we use the maximum distance to focus on these tests. On the other hand, after patched, the behaviors of all failing tests should change, so we use the average distance.

Please note this formula requires that we have at least a passing test, either original or generated. If there is no passing test, we simply treat the patch as correct.

5. Implementation

We have implemented our approach as a patch classification tool on Java. Given a Java program with a test suite and a patch on the program, our tool classifies the patch as correct or not.

In our implementation, we chose Randoop (Pacheco and Ernst, 2007), a random testing tool, as the test generation tool. Since our goal is to cover the patched methods, testing generation tools aiming to cover a specific location seem to be more suitable, such as the tools based on symbolic executions (Păsăreanu and Rungta, 2010) or search-based testing (Fraser and Arcuri, 2011). However, we did not use such tools because they are designed to cover the program with fewer tests. For example, Evosuite (Fraser and Arcuri, 2011) generates at most three test cases per each buggy program in our evaluation subjects. Such a small number of tests are not enough for statistical analysis.

6. Evaluation

The implementation and the evaluation data are available online. 111https://github.com/Ultimanecat/DefectRepairing

6.1. Research Questions

• •

RQ1: To what extent are TEST-SIM and PATCH-SIM reliable?

• •

RQ2: How effective is our approach in identifying patch correctness?

• •

RQ3: How is our approach compared with existing approaches, namely, anti-patterns, Opad, syntactic similarity and semantic similarity?

• •

RQ4: How does test generation affect the overall performance?

• •

RQ5: How do the parameters, $K_{t}$ and $K_{p}$, affect the overall performance?

• •

RQ6: What are the causes of false positive and false negatives?

• •

RQ7: How effective is our tool in classifying developers’ correct patches?

RQ1 examines how much TEST-SIM and PATCH-SIM hold in general. RQ2 focuses on the overall effectiveness of our approach. In particular, we are concerned about how many incorrect and correct patches we filtered out. RQ3 compares our approach with four existing approaches for identifying patch correctness. Anti-patterns (Tan et al., 2016) capture incorrect patches by matching them with pre-defined patterns. Opad (Yang et al., 2017) is based on inherent oracles that patches should not introduce new crashes or memory-safety problem. Syntactic similarity (Mechtaev et al., 2015; D’Antoni et al., 2016; Le et al., 2017) and semantic similarity (Le et al., 2017; D’Antoni et al., 2016) are patch ranking techniques that rank patches by measuring, syntactically or semantically, how much their changes the program, which could be adapted to determine patch correctness by setting a proper threshold. RQ4 and RQ5 explore how different configurations of our approach could affect the overall performance. RQ6 investigates the causes of wrong results in order to guide future research. Finally, as will be seen in the next subsection, though we have tried out best to collect the generated patches on Java, the correct patches were still small in number compared with incorrect patches. To offset this, RQ7 further investigates the performance of our approach on the developers’ correct patches.

6.2. Dataset

We have collected a dataset of generated patches from existing papers. Table 1 shows the statistics of the dataset. Our dataset consists of patches generated by six program repair tools. Among the tools, jGenProg is a reimplementation of GenProg (Weimer et al., 2009; Le Goues et al., 2012b, a) on Java, a repair tool based on genetic algorithm; jKali is a reimplementation of Kali (Qi et al., 2015) on Java, a repair tool that only deletes functionalities; Nopol (Xuan et al., 2016) is a tool that relies on constraint solving to fix incorrect conditions and two versions, 2015 (Martinez et al., 2016) and 2017 (Xuan et al., 2016), are used in our experiment; HDRepair (Le et al., 2016) uses information from historical bug fixes to guide the search process; ACS (Xiong et al., 2017) is a tool based on multiple information sources to statistically and heuristically fix incorrect conditions. The selected tools cover the three types of patch generation approaches: search algorithms (jGenProg, jKali), constraint-solving (Nopol) and statistical (HDRepair, ACS). More details of the three types can be found in the related work section.

The patches generated by jGenProg, jKali and Nopol2015 are collected from Martinez et al.’s experiments on Defects4J (Martinez et al., 2016). The patches generated by Nopol2017 are collected from a recent report on Nopol (Xuan et al., 2016). Patches generated by HDRepair is obtained from Xin and Reiss’ experiment on patch classification (Xin and Reiss, 2017). The patches generated by ACS is collected from ACS evaluation (Xiong et al., 2017).

All the patches are generated for defects in Defects4J (Just et al., 2014), a widely-used benchmark of real defects on Java. Defects4J consists of six projects: Chart is a library for displaying charts; Math is a library for scientific computation; Time is a library for date/time processing; Lang is a set of extra methods for manipulating JDK classes; Closure is optimized compiler for Javascript; Mockito is a mocking framework for unit tests.

Some of the patches are not supported by our implementation, mainly because Randoop cannot generate any tests for these patches. In particular, Randoop cannot generate any tests for Closure and Mockito. We removed these unsupported patches.

The patches from Martinez et al.’s experiments, the ACS evaluation and Qi et al.’s experiments contains labels identifying the correctness of the patches, which mark the patches as correct, incorrect, or unknown. The patches of Nopol2017 do not contain such labels. We manually checked whether the unlabeled patches and some labeled patches are semantically equivalent to the human-written patches. Since the patches whose correctness is unknown cannot be used to evaluate our approach, we remove these patches.

In the end, we have a dataset of 139 patches generated by automatic program repair tools, where 110 are incorrect patches and 29 are correct patches.

To answer RQ6, we also added all developer patches on Defects4J into our dataset. Same as generated patches, we removed the unsupported patches, including all patches on Closure and Mockito. In the end, we have 194 developer patches. Please note that developer patches are only used in RQ6 since they have different characteristics compared with generated patches.

6.3. Experiment Setup

**Test Generation. ** We kept Randoop to run 3 minutes on the original program and collected the tests that covered the patched methods. We stop at 3 minutes because for most defects, Randoop produced enough tests within three minutes, and for the remaining defects that do not have enough tests, lengthening the time would not lead to more tests. We then randomly selected 20 tests for each patch. If there were fewer than 20 tests, we selected all of them. In the end, we have 7.1 tests per patch in average, with a minimum of 0 test. Based on the classification of TEST-SIM, 71% of the generated tests are passing tests.

**RQ1. ** To evaluate PATCH-SIM, we measured the average distance between test executions of patched and unpatched versions, and check whether there is significant differences between passing and failing tests on correct and incorrect patches. To evaluate TEST-SIM, we measured the distances between tests, and analyzed whether closer distances indicate similar test results.

**RQ2. ** We applied our approach to the patches in our dataset and checked whether our classification results are consistent with the labels about correctness.

**RQ3. ** We applied the four existing approaches to the dataset and compared their results with our result.

Anti-patterns was originally implemented in C. To apply anti-patterns on Java dataset, we took the seven anti-patterns defined by Tan et al. (Tan et al., 2016) and manually checked whether the patches in our dataset fall into these patterns.

Opad (Yang et al., 2017) uses inherent oracles that patches should not introduce new crash or memory-safety problems. Opad was originally designed for C and we need to adapt it for Java. On the one hand, crashes are represented as runtime exceptions in Java. On the other hand, memory-safety problems are either prevented by the Java infrastructure or detected as runtime exceptions. Therefore, we uniformly detect whether a patch introduces any new runtime exception on test runs. If so, the patch is considered incorrect.

Regarding syntactic and semantic distances, different papers (Mechtaev et al., 2015; D’Antoni et al., 2016; Le et al., 2017) have proposed different metrics to measure the syntactic and semantic distances and a summary can be found in Table 2. However, as analyzed in the table, many of the metrics are defined for a specific category of patches and cannot be applied to general patches. In particular, many metrics are designed for expression replacement only and their definitions on other types of changes are not clear. As a result, we chose the two metrics marked as ”general” in Table 2 for comparison: one measuring syntactic distance by comparing AST and one measuring semantic distance by comparing complete-path spectrum.

The AST-based syntactic distance is defined as the minimal number of AST nodes that need to be deleted or inserted to change the one program into the other program. For example, changing expression $a>b+1$ to $c<d+1$ needs to at least remove three AST nodes ($a$, $b$, $>$) and insert three AST nodes ($c$, $d$, $<$), giving a syntactic distance of 6. The semantic distance based on complete-path spectrum for program $p$ is defined using the following formula, where $T_{o}$ is the set of all original tests that cover at least one modified method and $distance_{p}$ is defined in Section 4.4.2.

[TABLE]

The syntactic/semantic distance gave a ranked list of the patches. Then we checked if we could find an optimal threshold to separate the list into correct and incorrect patches.

**RQ4. ** We considered two different test generation strategies and compared their results with the result of RQ1.

• •

No generation. This strategy simply does not generate any test input. This strategy serves as a baseline for evaluating how much the newly generated test inputs contribute to the overall performance.

• •

Repeated Randoop runs. Since Randoop is a random test generation tool, different invocations to Randoop may lead to different test suites. This strategy simply re-invokes Randoop to generate a potentially different set of tests and the comparison helps us understand the effect of the randomness in test generation on the overall performance of our approach.

Since the second strategy involves re-generating the tests and is expensive to perform, we evaluated this strategy on a randomly selected subset of 50 patches. To see the effect of randomness, we repeated the experiments for 5 times.

**RQ5. ** During the experiments for the first three research questions, we set the parameters of our approach as follows: $K_{p}$ = 0.25, $K_{t}$ = 0.4. These parameter values are determined by a few attempts on a small set of patches.

To answer RQ4, we systematically set different values for parameters $K_{p}$ and $K_{t}$ and then analyzed how these parameters affect our result on the whole dataset.

**RQ6. ** We manually analyzed all false positives and false negatives to understand the causes of false classification and summarize the reasons.

**RQ7. ** We applied our approach on human-written patches provided by Defects4J benchmark and check whether our approach misclassified them as incorrect or not.

**Hardware Platform. ** The experiment is performed on a server with Intel Xeon E3 CPU and 32GB memory.

6.4. Result of RQ1: Reliability of Heuristics

Table 3 shows the results of evaluating PATCH-SIM, i.e., the distances between test executions on patched and unpatched versions. As we can see from the table, for correct patches, the distances of passing tests are very close to zero, while failing tests have a much larger distances that is 9.5 times of passing tests. The result indicates that PATCH-SIM holds in general. On the other hand, the passing tests and the failing tests do not exhibit such a strong property on incorrect patches. While the distances of failing tests are still larger than passing tests, the ratio is only 1.32 times rather than 9.5 times. This results indicate that PATCH-SIM can be used to distinguish correct and incorrect patches.

Figure 4 shows the results of evaluating TEST-SIM. The X-axis shows intervals of distances while the Y-axis shows the percentage of tests fall into the intervals. As we can see from the figure, when two tests have a short distance, they are more likely to have the same test results rather than different test results. This result indicates that TEST-SIM holds in general. On the other hand, when the two tests have a long distance, they are more likely to have different test results rather than the same test results.

6.5. Result of RQ2: Overall Effectiveness

Table 4 and Table 5 shows the performance of our approach on the dataset per tool and per project, respectively. As shown in the tables, our approach successfully filtered out 62 of 110 incorrect plausible patches and filtered out no correct patch. Furthermore, our approach shows similar performance on different tools and different projects, indicating that our results are potentially generalizable to different types of projects and different types of tools.

Please note that although our approach did not filter out any correct patch on our dataset, in theory it is still possible to filter out correct patches. For example, a patch may significantly change the control flow of a passing test execution, e.g., by using a new algorithm or calling a set of different APIs, but the test execution could produce the same result. However, given the status of current program repair approaches, such patches are probably scarce. When applying our approach on human-written patches, some correct patches are filtered out. More details for the effectiveness on human-written patch is discussed in RQ6.

Our approach took about 5 to 10 minutes to determine the correctness of a patch in most cases, while some patches might take up to 30 minutes. Most of the time was spent on generating the test inputs and recording the runtime trace.

6.6. Result of RQ3: Comparing with Others

**Anti-patterns. ** Among all 139 patches, anti-patterns filtered out 28 patches, where 27 are incorrect and 1 is correct. The result shows that our approach significantly outperforms anti-patterns. Furthermore, 13 of the 27 incorrect patched filtered out by anti-patterns were also filtered out by our approach, while the remaining 14 patches were not filtered out by our approach. This result suggests that we may potentially combine the two approaches to achieve a better performance.

**Opad. ** When applied with the same set of test inputs as our approach, Opad failed to recognize any of the incorrect patches. To further understand whether a stronger test suite could achieve better results, we further selected up to 50 tests instead of 20 tests for each patch. This time Opad filtered out 3 incorrect patches. This result suggests that inherent oracles may have a limited effect on classifying Java patches, as the Java infrastructure has already prevented a lot of crashes and memory safety problems and it may not be very easy for a patch to break such an oracle.

**Syntactic and Semantic Distance. ** Fig. 5 shows the distribution of incorrect patches and correct patches on syntactic distance. The x-axis shows the intervals of distances while Y-axis shows the numbers of patches within the intervals. As we can see from the figure, the incorrect patches and correct patches appear in all intervals and the distribution shows no particular characteristics. If we would like to exclude 56.3% incorrect patches using syntactic distance, we need to at least exclude 66.7% of the correct patches. This result indicates that syntactic distance cannot be directly adapted to determine patch correctness.

Fig. 6 shows the distribution of incorrect and correct patches on semantic distance. As we can see from the figure, both types of patches tend to appear more frequently when the distance is small. When the distance grows larger, both types decrease but correct patches decrease faster. If we would like to exclude 56.3% incorrect patches using semantic distance, we need to exclude 43.3% correct patches. This result indicates that semantic distance could be a better measurement than syntactic distance in determining patch correctness, but is still significantly outperformed by our approach.

Please note that the above results do not imply that syntactic and semantic distances are not good at ranking patches. While it is difficult to find a threshold to distinguish correct and incorrect patches for a group of defects, it is still possible that the correct patches are ranked higher on most individual defects.

6.7. Result of RQ4: Effects of Test Generation

Table 6 shows the result without generating test inputs. Without the generated test inputs, our approach filtered out 8 less incorrect patches and still filtered 0 correct patch. This result suggests that PATCH-SIM alone already makes an effective approach, but test generation and TEST-SIM can further boost the performance non-trivially.

Regarding randomness, we repeated our experiment on the selected 50 patches 5 times and got different results on only 3 incorrect patches. The best case had only one more excluded incorrect patch than the worst case. The result shows that randomness does affect the result, but the impact is limited.

6.8. Result of RQ5: Parameters

Two parameters are involved in our approach, $K_{t}$ and $K_{p}$, both ranging from 0 to 1. The results of our approach with different parameters are shown in Table 7 and 8, where each column shows the result with the parameter value in the table head. As we can see from the tables, setting the parameters to different values have a limited impact on the overall results and a large range of parameter value could achieve the best performance. The result indicates that our approach does not require a precise tuning of parameters.

6.9. Result of RQ6: Causes of Wrong Result

Our approach gave wrong results on 47 incorrect patches. We manually analyzed these patches and identified three main causes of the wrong classification, as follows.

**Too weak test suite. ** It is often the case (21 out of 48) that only one failing test covers the patched method. Without passing test, our approach only relies on the threshold $K_{t}$ to classify the tests and it is sometimes difficult to generate tests that pass the threshold. As a result, we might have no or only a few passing tests to perform the patch classification, leading to a low performance.

**Unsatisfying test generation. ** Another common case (27 out of 48, 9 overlap with the previous case) is that test generation tool fails to generate satisfying tests. Randoop might fail to give tests that cover the patched method or fail to generate tests that could expose the incorrect behavior. The patches in this category have the potential to be correctly identified if we use a stronger test generation tool.

**Unsatisfying classification formula. ** The final case (8 out of 48) was caused by large behavior changes in some failing test execution. Since we calculated the average distance of all failing test executions in the patch classification, if there was a very large value, the average value might become large even if all the rest failing tests had small behavior changes. As a result, the patch may be misclassified. This problem may be fixed by generating more failing test cases to lower down the average value, or to find a better formula to classify the patches.

6.10. Result of RQ7: Developer Patches

Among the 194 correct developer patches, our tool classified 16 (8.25%) patches as incorrect. We further analyzed why the 16 patches are misclassified and found that all the 16 patches have non-trivially changed the control flow and caused a significant difference in CPS in the passing test executions. In particular, the behaviors of passing tests have significantly changed in 6 patches, while in the rest 10 patches the behaviors remain almost the same but the executed statements changed significantly (e.g., calling a different method with the same functionality). The results imply that (1) human patches are indeed more complex than those generated by current automated techniques; (2) when the complexity of patches grows, our approach is probably still effective as only a small portion of correct patches is excluded; (3) To further enhance the performance, we need to enhance PATCH-SIM and CPS to deal with such situations.

7. Threats to Validity and Limitations

The main threat to internal validity is that we discarded some patches from our dataset, either because their correctness cannot be determined, or because the infrastructure tool used in our implementation cannot support these patches. As a result, a selection bias may be introduced. However, we believe this threat is not serious because the removed patches are small in number compared with the whole dataset and the results on these patches are unlikely to significantly change the overall results.

The main threat to external validity is whether our approach can be generalized to different types of program repair tools. While we have selected repair tools from all main categories of program repair tools, including tools based on search algorithms, constraint solving and statistics, it is still unknown whether future tools will have characteristics significantly different from current tools. To minimize such a threat, we have added RQ7 to test on developer patches, which can be viewed as the ultimate goal of automatically generated patches. The results indicates that our approach may have different performance on developer patches and generated patches, but the difference is limited.

The main threat to construct validity is that the correctness of the patches are manually evaluated and the classification may be wrong. To reduce this threat, all difficult patches are discussed through the first two authors to make a mutual decision. Furthermore, part of the classification comes from Martinez et al.’s experiment (Martinez et al., 2016), whose results have been published online for a few years and there is no report questioning the classification quality as far as we are aware.

There can be many different choices in designing the formulas. For example, we can use a different sequence distance or even a different spectrum to measure the distance of two executions. We can use different statistical methods for classifying tests and patches. The current paper does not and cannot explore all possibilities and leave them as future work.

8. Conclusion

In this paper, we have proposed an approach to automatically determining the correctness of the patches based on behavior similarities between program executions. As our evaluation shows, our approach could effectively filter out 56.3% of the incorrect patches generated without losing any of the correct patches. The result suggests that measuring behavior similarity can be a promising way to tackle the oracle problem and calls for more research on this topic.