Have Java Production Methods Co-Evolved With
Test Methods Properly?: A Fine-Grained
Repository-Based Co-Evolution Analysis
Tenma Kita∗ , Hirohisa Aman† , Sousuke Amasaki‡ , Tomoyuki Yokogawa‡ and Minoru Kawahara†∗ Department of Computer Science, Faculty of Engineering, Ehime University

Matsuyama, Ehime, 790–8577 Japan† Center for Information Technology, Ehime University

Matsuyama, Ehime, 790–8577 Japan‡ Faculty of Computer Science and Systems Engineering, Okayama Prefectural University

Soja, Okayama, 719–1197 Japan

Abstract—Any source code of a software product (productioncode) is expected to be tested to ensure its correct behavior.
Whenever a developer updates production code, the developer
should also update or create the corresponding test code to checkif the updated parts still work correctly. Such a desirable coevolution relationship between production and test code forms
a logical coupling. Although the logical coupling is detectablethrough an association analysis on the code repository such as
Git, the detection granularity is coarse because the conventional
repository is at the ﬁle level. For observing those logical couplings
as precisely as possible, this paper utilizes the ﬁner-grained, Javamethod-level repository (FinerGit). Then the paper proposes a
metric measuring the extent to which a production method has
co-evolved with test methods and conducts a case study using ten
open-source projects. The results show that most Java methods(98% on average) have co-evolved with test methods, but somehave not; The proposed metric helps detect those methods having
the potential risk that the developers might not test adequately.
Index Terms—logical coupling, metric, co-evolution between
production and test code, ﬁne-grained code repository

I. I NTRODUCTION
Software products usually evolve through various sourcecode changes, including new code additions, existing code
deletions, or modiﬁcations [1]. Although source code changes
are inevitable in the successful software evolution, they alsorisk introducing new bugs into the software product [2]. Hence,developers should test their products whenever they update thesource code. To this end, when developers change the product’s source code (production code), the developers should also
create or modify the test code (unit test cases) corresponding
to the updated production code [3], [4]. Moreover, even whendevelopers ﬁx bugs in production code, they should add or
modify their test code because the existing test code has failed
to detect those bugs. Therefore, it is ideal that any production
code needs to co-evolve with the corresponding test code [5].
We can observe such a co-evolution as a logical coupling [6]between production and test code.
Logical couplings between two software artifacts (e.g.,source ﬁles) are detectable through association analysis in
the software repository [7]—If one artifact’s change appears

in a commit, how likely is another artifact’s change also
to appear in the same commit? The granularity of logicalcoupling detection depends on the unit of commits to thecode repository. Since the commit unit of prevailing code
repositories such as Git is a ﬁle, the logical coupling detectionis also at the ﬁle level. However, because the implementation
unit of a product’s functionality or a test case can be ﬁnergrained (e.g., method or function), a ﬁle-level analysis seems
to be coarse and insufﬁcient. To overcome this issue of
granularity, we utilize a ﬁne-grained code repository, FinerGit
developed by Higo et at. [8], in this paper. FinerGit can convert
the conventional ﬁle-level Git repository of Java software to amethod-level one and allow us to analyze the logical couplings
between production and test code at the Java method level.
Although there have been studies regarding ﬁne-grained coevolution cases (logical couplings) between production andtest code [5], [9], [10], their main focuses were on understanding the evolution patterns. There may also be problematic
production code that has not been co-evolved with test codein practice, and such a production code was out of scopein the above co-evolution pattern analyses because it had
weak or no logical coupling with the test code and thus did
not appear in the association rules. Nonetheless, to prevent
unexpected regressions during software evolution, detecting
such a production code having poor or no logical couplingwith the test code is still signiﬁcant. In this paper, to detect
the above potentially problematic production code (method)
automatically, we propose a metric for evaluating the logicalcoupling of a production method with test methods by utilizing
a state-of-the-art ﬁne-grained code repository.
II. R ELATED W ORK
Luben et al. [9] emphasized the successful maintenance oftest cases in test-driven development. They conducted casestudies of co-evolution between production and test code using
two software development projects. Their study regarded Javaclasses and JUnit classes as production and test code, respectively, and performed association analyses between them.

Then, they identiﬁed some logical couplings between Javaproduction classes and JUnit test classes in those software
products, but the strength of coupling differed from project
to project. Although the work by Luben et al. is a valuableprevious study of the production-test code co-evolution relationships, the analysis is at class-level and coarse-grained. To
analyze those relationships from a ﬁner-grained point of view,
we utilize a method-level code repository in this paper.
Marsavina et al. [5] performed a ﬁne-grained code change
analysis to extract co-evolution patterns between production
and test code. They utilized ChangeDistiller [11] to examine
code changes in a detailed manner. Furthermore, they built(compiled) and ran the test programs for each revision of
the studied software products and analyzed test coverages.
Through those rich code analyses on ﬁve open-source development projects, Marsavina et al. found six primary co-evolution
patterns, such as “a production class addition/removal tends tocause a test class addition/removal.” Vidács and Pinzger [10]conducted a replication study of [5] and reported that they also
identiﬁed the same six co-evolution patterns but the logicalcouplings between production and test code were weaker thanthat Marsavina et al. reported.
The previous studies [5], [10] yield profound insights intoco-evolution relationships between production and test code
through their detailed and rich change analyses. Moreover,they performed manual qualitative analyses of co-evolution
patterns and found some problematic production methods (production code) that were not covered by any test code. Althoughpoor-tested production code is out of their co-evolution pattern
extractions, it is also vital to automatically detect such aproblematic production code to make the developers awareof them for successful software evolution. Thus, we aim todetect problematic methods having poor or no logical couplingwith the test methods by quantifying the extent to whicha production method has co-evolved with test methods. We
can easily evaluate logical couplings between production andtest methods without any rich code analysis performed in
the previous work [5], [10] since we utilize a Java-methodlevel code repository [8] rather than the conventional ﬁle-levelrepository in this paper.
III. L OGICAL C OUPLING B ETWEEN P RODUCTION AND
T EST M ETHODSThis section brieﬂy describes the logical coupling between
production and test methods. Notice that our approach relieson the assumption that the developers commit their co-change
events to the Git repository in a disciplined manner.
A. FinerGit: A Fine-Grained Repository For Java Methods
Higo et al. [8] developed “FinerGit,” a Git-based tool thatallows easy version control of Java methods. The tool converts
a Git repository managing Java source ﬁles into another Git
repository with the following two features.
(1) Manage a Java method as a ﬁle: FinerGit extracts
Java methods from source ﬁles and stores the methods inseparate ﬁles. Each ﬁle contains a single method, and theﬁle name corresponds to the method’s signature as “className#methodSignature.mjava.” Then, the tool produces a new
Git repository to represent all the past code changes regarding
Java methods as “commits” of the corresponding “.mjava”
ﬁles. We can explore the change history of Java methods using
the conventional Git commands in the produced repository.
Therefore, we can efﬁciently perform the co-evolution analysis
of Java methods without any rich program analysis techniques.
(2) Store a method in the one-token per line style: Amjava ﬁle maintains the corresponding method in the onetoken per line style. One-token per line style aids the Git
repository in successfully tracking the method renames andsignature changes. Git repository has a function to keep trackof renaming a ﬁle at a commit. Suppose both a ﬁle deletion
and a ﬁle addition occur at the same commit, and the similarity
between those two ﬁles is higher than a certain threshold1 . In
that case, Git regards it as a ﬁle “renaming” rather than apair of ﬁle deletion and addition. For evaluating the similarity
between two ﬁles, the repository computes the hash value
for each line (or 64-byte block) of the ﬁles and compares
their hash-value distributions. However, such a Git’s renamedetection mechanism is likely to miss method-renaming cases
and method signature-changing cases because many small
methods consist of a few lines of code. Hence, FinerGit adopts
the one-token per line style to overcome such a challenge.
B. Logical Coupling Between Production and Test Methods
Suppose M is the set of production methods, and T is theset of test methods. Now we consider a co-evolution between
a production method mp (∈ M ) and a test method mt (∈ T )with the following association rule: if the developers change
mp , they also change mt . We denote that rule by “mp ⇒ mt .”Moreover, we denote the number of co-change commits where
the developers changed both mp and mt , by “σ(mp ∧ mt ).”Notice that we can track the method-renaming and signaturechanging cases mentioned in Section III-A and include themin the count of co-change commits. Similarly, let σ(mp ) be thenumber of commits changing mp . Then the following value
is called the conﬁdence of mp ⇒ mt :conf (mp ⇒ mt ) =σ(mp ∧ mt ).
σ(mp )

The conﬁdence value indicates a likelihood of the co-change
occurrence when mp is changed. Hence, we can regard
conf (mp ⇒ mt ) as a conditional probability of co-change,
P (mt is changed | mp is changed).
We can detect logical couplings between methods by focusing on the conﬁdence value. A conﬁdence value presents
the strength of logical coupling. Notice that the above logicalcoupling detection relies on the developers’ commit manners;
if they did not commit their production methods and the corresponding test methods simultaneously, we fail to detect theircouplings. We need to employ an advanced detection approachto cover such a delayed (time-lagged) logical coupling, and it
is our signiﬁcant future work.
1 Git’s default threshold is 50%.

C. Evaluation Metric
Whenever a developer adds a new production method or
updates an existing one, the developer should also add oredit the test method corresponding to the added/updated parts
to avoid unexpected regressions. We propose a metric forevaluating the certainty that a production method’s change
links to one or more test methods’ changes below.
Here we deﬁne the following extended conﬁdence value
conf ∗ (mp,i ) since there may be two or more corresponding
test methods for one production method:∗

conf (mp,i ) = 1 −

|T |
∏
{

}

1 − conf (mp,i ⇒ mt,j ) ,j=1

where mp,i is the i-th method in our production method set(M ), and mt,j is the j-th method in our test method set (T ).
conf ∗ (mp,i ) is the probability that a change of mp,i links
to at least one test method’s change. In other words, a low
conﬁdence value indicates that the production method has notco-evolved with any test methods successfully.
conf ∗ (mp,i ) evaluates the logical coupling of the production method mp,i with any test methods mt,j (∀j). Furthermore, we also need to consider the logical coupling of the production method mp,i with other production methods because
there may be indirect relationships between production and test
methods. For example, suppose there is a production method
mp,k calling other production methods mp,k+1 and mp,k+2 . In
that case, the developer might prepare test methods only forthe callee methods (mp,k+1 and mp,k+2 ) because those test
methods indirectly test the caller method (mp,k ). We propose
the following metric covering both the direct and the indirect
relationships between production and test methods:
Tconf (mp,i )
|M |
∏{
}
1 − conf (mp,i ⇒ mp,k ) · conf ∗ (mp,k ) .
=1−
k=1

In the above equation, “conf (mp,i ⇒ mp,k ) · conf ∗ (mp,k )”presents the joint probability of the following (i) and (ii):(i) mp,i co-evolves with mp,k , and (ii) mp,k co-evolves withat least one test method. Thus, “1 − conf (mp,i ⇒ mp,k ) ·conf ∗ (mp,k )” represents the probability that mp,i does notco-evolve with any test methods via mp,k . By considering
the joint probability of them for all production methods, ourmetric Tconf (mp,i ) evaluates the likelihood that the production method mp,i co-evolves with at least one test method ineither direct or indirect manners. In other words, a production
method with a low Tconf value might be problematic as it
has not been co-evolved with test methods.
IV. C ASE S TUDY
We conducted a case study using ten Apache top-level opensource projects (see Table I) to demonstrate how the proposed
metric Tconf helps detect the problematic Java methods thathave not been co-evolved with test methods. We report anddiscuss the study results in this section.

TABLE IS TUDIED P ROJECTS
Project Name
(Git repository)
Curator (curator.git)
Fineract (ﬁneract.git)
Flume (ﬂume.git)
Maven (maven.git)
Parquet(parquet-mr.git)
PDFBox (pdfbox.git)
Ranger (ranger.git)
RocketMQ(rocketmq.git)
Shiro (shiro.git)
Zookeeper(zookeeper.git)

Data Collection
# of
# of
PeriodCommits Methods
2011-07-14 – 2021-12-15
2,739
3,876
2012-04-20 – 2021-12-17
6,368
21,141
2011-08-09 – 2022-01-14
1,832
5,105
2003-09-01 – 2021-12-17
11,502
7,481
2012-08-31 – 2021-12-16

2,320

6,574

2008-02-10 – 2021-12-20
2014-08-14 – 2021-12-17

10,5393,760

11,768
13,9792016-12-20 – 2022-01-19

1,955

8,742

2005-07-14 – 2022-01-15

2,210

4,088

2008-03-19 – 2021-11-27

2,371

7,498

A. Results
We extracted 71,730 Java production methods and 18,522
test methods from the studied projects; we regarded the Javamethods in Java source ﬁles whose paths include “test”
as the test methods and considered the remaining ones as
the production methods. Then, we computed Tconf values
for each production method. As a result, most values wereapproximately 1.0, and the average Tconf values were 0.9557– 0.9996 for all projects2 .
Table II presents the percentage of methods classiﬁed bythree categories: “Tconf ≃ 1,” “0.5 ≤ Tconf ≤ 0.999,” and“0 ≤ Tconf < 0.5,” where we regard “0.999 < Tconf ≤ 1”
as Tconf ≃ 1 by considering round-off errors of ﬂoating point
numbers in our Tconf computation. As a result, about 98%
of production methods show Tconf ≃ 1 on average. Those
results indicate that most production methods have co-evolved
with test methods in the ten studied projects.
However, Table II shows that some production methods
have low Tconf values, i.e., they have not co-evolved withtest methods. Here, we focus on the production methods
whose Tconf values are less than 0.5; Since the co-change
probability is less than 0.5, such a production method is
not likely to co-evolve with test methods, and it might be
a problematic method from the viewpoint of testing. The
percentages of such problematic methods were less than 1%
in nine out of ten projects (see Table II). Only the PDFBox
project showed a different tendency from the others, and thepercentage of such production methods was 3.87%.
B. Discussions
We conducted a case study using ten open-source softwaredevelopment projects to observe how the proposed metric
Tconf works to detect problematic production Java methods
from the viewpoint of the co-evolution relationship between
production and test methods. As a result, we found that theTconf values of about 98% of production methods are approximately equal to 1, i.e., those production methods have coevolved with one or more test methods. Thus, we can say that
2 The set of experimental data obtained in this study is available at our
supplemental data site https://bit.ly/3Ekurdc.

TABLE IIP ERCENTAGES OF PRODUCTION METHODS CLASSIFIED BY Tconf VALUES
Project Name
CuratorFineract
Flume
Maven
ParquetPDFBoxRangerRocketMQ
Shiro
Zookeeper
AverageTconf < 0.5
0.43%
0.04%
0.27%
0.76%
0.13%
3.87%
0.46%
0.29%
0.03%
0.37%
0.67%

0.5 ≤ Tconf ≤ 0.999
0.64%
0.04%
0.59%
1.94%
0.04%
7.65%
1.92%
0.12%
0.23%
0.13%
1.33%

Tconf ≃ 1
98.93%
99.92%
99.14%
97.30%
99.82%
88.49%
97.62%
99.59%
99.74%
99.49%
98.00%

the developers have successfully developed and maintained
most Java production methods with the test methods in thestudied projects.
Nonetheless, we also found some production methods withlow Tconf values. For example, Tconf value of method“PDPropBuildDataDict#public String getVersion” in the
PDFBox (Fig. 1) was zero. We explored the method-levelrepository and noticed it appeared in the commit history
only once. That is, the method has not been changed after
its creation. Although that method was a simple “getter”
method, as shown in Fig. 1, it would be better to prepare thecorresponding test method. However, some developers might
not make unit test cases for such simple methods in practicebecause they look less likely to be buggy.
We take the existence of simple production methods likeFig. 1 into account and ﬁlter out the production methods
satisfying both of the following two conditions: (i) it has
appeared in the commit history only once, and (ii) it has thelowest cyclomatic complexity [12], i.e., it contains no branchstatement (e.g., if, for, while); The lowest cyclomatic
complexity (=1) indicates that the method has a single execution path and is the most straightforward code under test.
Table III shows the number and percentage changes of the
problematic production methods whose Tconf values are lessthan 0.5 before and after ﬁltering the simple methods out.
As shown in Table III, all production Java methods withTconf < 0.5 disappeared in six out of ten projects through theabove ﬁltering, and a few stayed in three out of the remaining
four projects. Although all projects showed a signiﬁcantdecrease in such methods, only the PDFBox project still has
many (=118; 1.14%). We found a Java production method“addPath(PDAppearanceContentStream,GeneralPath)”of class “PDTextAppearanceHandler” in package “org.apache.pdfbox.pdmodel.interactive.annotation.handlers,”
whose LOC = 44 and cyclomatic complexity = 7. While thismethod has appeared in the commit history twice, it has not

public String getVersion(){
return dictionary.getString("REx");}Fig. 1. Source code of PDPropBuildDataDict#public String getVersion.

TABLE IIIN UMBER AND PERCENTAGE OF PRODUCTION METHODS WITH
Tconf < 0.5 BEFORE AND AFTER FILTERING THE SIMPLE ONES OUT
Project Name
CuratorFineract
Flume
Maven
ParquetPDFBoxRangerRocketMQ
Shiro
Zookeeper# of Methods (Percentage)
Before Filtering
After Filtering
12 (0.43%)
0 (0.00%)
7 (0.04%)
0 (0.00%)
7 (0.27%)0 (0.00%)
44 (0.76%)
1 (0.02%)
6 (0.13%)0 (0.00%)403 (3.87%)
118 (1.14%)
55 (0.46%)
6 (0.05%)
20 (0.29%)
3 (0.04%)
1 (0.03%)0 (0.00%)
17 (0.37%)
0 (0.00%)

been co-evolved with any other production or test methods,i.e., its Tconf value is zero. Since the method is not simple
in terms of LOC and cyclomatic complexity, it is ideal toco-evolve with one or more corresponding test methods during
the development. Nevertheless, it can be a potential problem
that the method also has no (indirect) logical coupling to any
test methods (Tconf = 0). Although developers might test
such a method in another way, we consider it is worth it toalert the presence of such a production method and make thedevelopers aware of the risk of missing the method’s test to
prevent unexpected regressions.
Finally, we discuss the differences among projects from theviewpoints of the production-test method ratio and the numberof developers. Table IV compares projects using two metrics:
PTR (Production-Test method Ratio),
number of production methods,
number of test methods
and NDEV (Number of DEVelopers). The higher PTR value
indicates fewer test methods for the production ones in the
project. As the PDFBox project has the second-highest PTR
value, following the Fineract project (see Table IV), thesetwo projects prepare fewer test methods for the number of
their production methods than the other projects. However,
NDEV values differ substantially between these two projects:
the NDEV value of the Fineract project is 164, and that of the
PDFBox project is only 6. Hence, the testing of production
methods may depend on a small group of developers, andthere would be a higher risk of overlooking regressions during
maintenance activities.
PTR =TABLE IV
A COMPARISON OF PROJECTS USING PTR AND NDEV
Project Name
CuratorFineract
Flume
Maven
ParquetPDFBoxRangerRocketMQ
Shiro
Zookeeper

PTR
2.6
8.3
1.0
3.5
2.2
7.8
5.9
3.6
5.0
1.5

NDEV
108
164
55
151
166
6
88
320
56
163

Notice that a low Tconf value does not directly indicate
the poor quality of the production method. Nonetheless, theproposed metric Tconf can detect the methods that have notbeen successfully co-evolved with test methods. By alerting
such potentially problematic production methods to the developers, Tconf can contribute somewhat to the successful
software evolution. We plan to validate the usefulness of ourmetric by asking the developers for feedback in the future.
C. Threats to Validity
1) Construct Validity: We proposed the metric Tconf tomeasure how a Java production method has properly coevolved with one or more test methods. Our measurement
is based on the co-change events (commits) of Java methods
observed in the code repository. Thus, the fundamental factor
is the number of commits in which both the production andthe test method changed. However, there might be cases where
the test code’s commits occurred after the production code’s
commits [13]. Such a delayed logical coupling is a threat
to the construct validity in this study, and we need further
investigation regarding it in the future.
2) Internal Validity: Because we often see the commits
involving changes in methods’ names and signatures, it is
crucial to accurately track the renaming commits in themethod-level repository. In other words, the accuracy of therename-commit tacking is a threat to the internal validity ofthis study. To mitigate the threat, we utilized the state-ofthe-art tool (FinerGit) that outperforms the conventional one(Historage [14]) regarding rename tracking accuracy. However,if there was a renaming commit with many code changes,
we might mistakenly treat it as a pair of method additionand deletion. Furthermore, some changes in production methods might be non-functional changes such as refactoring orcomment changes. As such changes do not require test codechanges, our metric may make some false-positive alerts. We
need to employ a richer code-change analysis to control suchfalse-positive cases, and it is our signiﬁcant future work.
3) External Validity: Our case study examined ten Apache
top-level projects. Although they are popular and wellmanaged projects, they cannot become the representative ones
reﬂecting all Java software developments. Different projects
driven by other organizations or individuals may have different
styles of managing their test methods. Especially, it would be
an impactful factor if they adopt the test-driven development
or not. Moreover, our study did not investigate projects with
development languages other than Java. The above things canbe threats to the external validity of this study.
V. C ONCLUSION AND F UTURE W ORK
Whenever a production method is changed, the corresponding test methods are ideal to be updated or created to test
the modiﬁed code at the same commit. Such co-evolution
relationships ensure successful software maintenance and evolution. Thus, we focused on the co-evolution (logical coupling)
between production and test methods and utilized FinerGit to
track method-level code change history in this paper. Then,

we proposed Tconf as a metric for evaluating how a Javaproduction method has properly co-evolved with test methods.
Through a case study of Tconf using ten open-source Javasoftware development projects, we showed most production
methods (about 98% on average) had been co-evolved withtest methods successfully, but some methods were not; We
could detect the potential problematic production methods thathave not been co-evolved with any test method using the
proposed metric Tconf . Although it does not directly imply
those production methods are poor quality, it is worth it tomake the developers aware of the potential risk that they might
not test those methods adequately. The proposed metric Tconf
is helpful to alert such production methods.
Our future work includes (1) a validation study of Tconf bygetting feedback from the developers, (2) an empirical studyof the relationship between Tconf value and the overlooked
faults, and (3) further analyses focusing on the code changedetails and the delayed logical couplings where the test
method’s commit occurs after the production one’s commit.
ACKNOWLEDGMENT
This work was supported by JSPS KAKENHI #20H04184,#21K11831, and #21K11833.
R EFERENCES[1] I. Sommerville, Software Engineering, 10th ed.
Essex: Pearson
Education, 2016.
[2] C. Jones, Applied Software Measurement: Global Analysis of Productivity and Quality, 3rd ed. New York: McGraw-Hill, 2008.
[3] S. Elbaum, D. Gable, and G. Rothermel, “The impact of software
evolution on code coverage information,” in Proc. IEEE Int’l Conf.
Softw. Maintenance, Nov. 2001, pp. 170–179.
[4] A. Zaidman, B. Van Rompaey, S. Demeyer, and A. van Deursen,“Mining software repositories to study co-evolution of production amp;
test code,” in Proc. 1st Int’l Conf. Softw. Testing, V. & V., Apr. 2008,
pp. 220–229.
[5] C. Marsavina, D. Romano, and A. Zaidman, “Studying ﬁne-grained coevolution patterns of production and test code,” in Proc. 14th IEEE
Int’l Working Conf. Source Code Analysis & Manipulation, 12 2014,
pp. 195–204.
[6] H. Gall, K. Hajek, and M. Jazayeri, “Detection of logical coupling basedon product release history,” in Proc. Int’l Conf. Softw. Maintenance, Nov.
1998, pp. 190–198.
[7] T. Zimmermann, P. Weibgerber, S. Diehl, and A. Zeller, “Mining version
histories to guide software changes,” in Proc. 26th Int’l Conf. Softw.
Eng., Jul. 2004, pp. 563–572.
[8] Y. Higo, S. Hayashi, and S. Kusumoto, “On tracking java methods withgit mechanisms,” J. Syst. Softw., vol. 165, pp. 110 571:1–13, Jul. 2020.
[9] Z. Lubsen, A. Zaidman, and M. Pinzger, “Using association rules tostudy the co-evolution of production amp; test code,” in Proc. 6th IEEE
Int’l Working Conf. Mining Softw. Repo., May 2009, pp. 151–154.
[10] L. Vidács and M. Pinzger, “Co-evolution analysis of production andtest code by learning association rules of changes,” in Proc. 2018 IEEE
Workshop Machine Learning Tech. for Softw. Q. Eval., Mar. 2018, pp.
31–36.
[11] B. Fluri, M. Wursch, M. PInzger, and H. Gall, “Change distilling:tree
differencing for ﬁne-grained source code change extraction,” IEEE
Trans. Softw. Eng., vol. 33, no. 11, pp. 725–743, Nov. 2007.
[12] T. McCabe, “A complexity measure,” IEEE Trans. Softw. Eng., vol. SE2, no. 4, pp. 308–320, Dec. 1976.
[13] A. Zaidman, B. V. Rompaey, A. van Deursen, and S. Demeyer, “Studying
the co-evolution of production and test code in open source and industrial
developer test processes through repository mining,” Empr. Softw. Eng.,
vol. 16, no. 3, pp. 325–364, Jun. 2011.
[14] H. Hata, O. Mizuno, and T. Kikuno, “Bug prediction based on ﬁnegrained module histories,” in Proc. 34th Int’l Conf. Softw. Eng., May
2012, pp. 200–210.