A Trend Analysis of Test Smellsin Python Test Code Over Commit History
Yuki Fushihara∗ , 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—Software testing is an essential activity for developing and maintaining high-quality software. Unit testing with testcode (test cases) is a fundamental testing activity, and developers
can test their production code whenever they create or modify thecode. However, such quality assurance relies on the correctnessof the test code. If a test code had a ﬂaw, it would mislead thedevelopers about the hidden faults and prevent early detection of
the faults. This paper focuses on “test smells,” which may cause
test code ﬂaws in Python programs, and analyzes their changing
trends over commit history (code changes) toward better Python
test code management. Through an empirical data analysis of 100
open-source projects, the paper reports the following ﬁndings:(1) a few kinds of test smells constitute the majority of smells
detected in the studied projects, and (2) most kinds of smells
tend to increase over commits, i.e., many test smells are likely tohave remained in test code as technical debt.
Index Terms—unit testing, test smell, technical debt, commit
history, trend analysis

I. I NTRODUCTION
Unit testing is the most fundamental software testing activity
that can detect latent faults as early as possible during softwaredevelopment and maintenance. The unit testing framework(e.g., xUnit [1]) provides a helpful mechanism for automatically testing software modules. Under a unit test framework,
developers prepare test code for their production code andcan quickly test their products whenever they newly create or
modify their production code [2]. Such an automated test environment can assist developers in developing and maintaining
their programs successfully.
However, the quality assurance of software modules using
an automated testing environment with unit test code depends
on the reliability of the prepared test code. A test code is alsoa source code written by a human being and has a risk oftesting the production code improperly. In other words, sometest code might overlook latent faults in the production codeand mislead the developers with erroneous test results. For
example, if a test code has a conditional branch statement,
there is a risk that the test code does not test the production
code properly because the test engineer might write a ﬂawed
condition in the branch statement. Such a risky feature is akind of “code smells” [3] in the test code.

Although such smells in test code may not directly cause
improper testing, they can become a technical debt for thesoftware product. Thus, it is ideal for detecting problematic
test code and performing refactorings to reduce the risk of
unreliable tests. Some undesirable features of test code havebeen studied as “test smells” [4] in the past. Recently, Wang etal. [5] developed a tool for detecting 18 different kinds of test
smells in Python test code and reported that a few kinds oftest smells are likely to appear in many test cases. While theirtool is helpful and their reports are noteworthy, the changing
trend of test smells has not been analyzed and discussed well.
In other words, although their reports showed which kind oftest smells are frequently detected, they missed analyzing thetrend of test smells through the development and maintenanceactivities.
For example, suppose we observe a test smell that tends toincrease through code changes. It would be a kind of test smellthat developers and test engineers are likely to overlook, andthe smelled test code would survive for an extended period
as a potential risk of causing unreliable tests. We conducteda large-scale data analysis of test smell trends in 100 opensource Python projects to explore test smells from the timeseries perspective. In this paper, we report our data analysis
and discuss the results to present fundamental data of test smellchanging trends toward adequate test code management.
II. T EST S MELLS IN P YTHONIn this section, we brieﬂy describe the Python unit testing
framework of interest and the concept of test smells. Then we
discuss the related work and our research motivation.
A. Unit Testing Framework and Test Smells
There have been some unit testing frameworks to automatically perform unit testing of Python programs and report thetesting results. We focus on unittest in this paper because it is
one of the most popular and fundamental testing frameworks
for Python. Fig. 1 presents a simple example of Python testcode based on unittest, which tests a function “fizz_buzz.”
A test case is a subclass of “unittest.TestCase,” andit has some test methods whose names begin with “test.”

import unittest
class TestFizzBuzz(unittest.TestCase):
def test_fizz_buzz(self):
for value in range(1,31):
if value in [3,6,9,12,18,21,24,27]:
expected = "Fizz"
elif value in [5,10,20,25]:
expected = "Buzz"
elif value in [15,30]:
expected = "Fizz Buzz"
else:
expected = str(value)
actual = fizz_buzz(value)
self.assertEqual(expected, actual)

Fig. 1. An example of test case having test smells.

The unit test runner executes those test methods and reports
the results. Each test method runs the production code under
test and checks if it behaves as expected using the assertion
methods provided by the framework. In the example of Fig. 1,
the “assertEqual” method checks if the actual value equals
the expected one.
Whenever developers create a new Python program ormodify an existing one, they can automatically test those newor modiﬁed programs using the test cases under the unit testing
framework. Such an automated testing environment helps
developers detect latent faults quickly. However, it should be
noted that the successful cycle of coding and testing depends
on the test cases’ reliability. Suppose some of the prepared
test cases are incorrect and overlook some faults. In that case,the program under test may pass all tests even if it is buggy,
and the test results would mislead the developers while giving
a false sense of reassurance. Because a unit test case is also a
program written by a human being, there is always a risk of
producing an erroneous test code [6].
Some problematic characteristics of source code to be
refactored have been studied as “code smells” [3] in the past.
Although source code with a smell does not always cause
trouble in development and maintenance, it has a higher riskof becoming buggy or hard-to-understand code and can be atechnical debt. Because test code is also source code, a similar
concept is applicable to test code and is referred to as “testsmell” [4]. When a test code has a test smell, it is better torefactor it to remove the smell to enhance the test’s reliability
toward the successful development of high-quality production
code.
B. Related Work and Research Motivation
Deursen et al. [4] ﬁrst introduced the concept of test
smells. They focused on the difference in refactoring between
production code and test code. Through an investigation of thetest code refactoring, Deursen et al. discovered that test codealso tends to have code smells that differ from the well-known
code smells in production code, and then they presented 11
test smells and the refactorings for those smells. After that,
Meszaros et al. [1] and Greiler et al. [7] ramped up the kindof test smells. Spandini et al. [8] reported that test smells might
adversely affect both the test and production codes, as follows:(1) the test code with a test smell is more change-prone andfault-prone than the other test code, and (2) the production

TABLE IT EST SMELLS SUPPORTED BY P Y N OSE
Test Smell
Assertion Roulette
Conditional Test Logic
Constructor
Initialization
Default Test
Duplicate Assert
Empty Test
Exception Handling
General Fixture

Description
An AS has no explanation/message in a TC.
A control statement—if, for, while—is used.
A constructor is declared in a TS.

A TS is called MyTestCase.
Two or more ASs have the same parameters.
No executable statement appears in a TC.
A try/except or raise statement is used.
Not all ﬁelds instantiated within setUp()of a TS are utilized by all TCs.
Ignored Test
A @unittest.skip decorator is used.
Lack of Cohesion of
The mean of cosine similarities of
Test Cases
all TC pairs ≤ 0.4.
Magic Number Test
A numeric literal is used as an argumentof an AS.
Obscure In-Line Setup A TC declares ten or more local variables.
Redundant Assertion
An AS has a condition that is always true,e.g., assertEqual(X,X).
Redundant Print
print() is used in a TC.
Sleepy Test
time.sleep() is used with no comments.
Suboptimal Assert
A suboptimal assert is used in a TC.
Test Maverick
A TC does not use any ﬁeld from setUp().
Unknown Test
No AS is used in a TC.
(AS: assertion statement, TC: test case, TS: test suite)

code tested by a smelled test code is also more fault-prone
than the other production code. Hence, detecting test smells
and resolving their problems as early as possible is crucial for
successful software development and maintenance.
There have been studies of test smell detection and automated detection tools [9]–[12]. Recently, to support Python
programs, Wang et at. [5] developed a test smell detection tool,
PyNose, to distill 18 kinds of test smells (see Table I) fromtest code automatically. Through a case study examining opensource projects, they empirically showed PyNose successfully
detects test smells and reported some test smells, such as“Assertion Roulette,” “Conditional Test Logic,” and “Magic
Number Test,” tend to appear in many Python test code. For
instance, the test case shown in Fig. 1 has a smell categorized
as “Conditional Test Logic” because it contains conditional
branches. Although its risk of making mistakes is low because of the code simpleness, it would be better to describe
assertion methods corresponding to straightforward test casessuch as (3, "Fizz"), (4, "4") and (5, "Buzz"), formaking the test case more readable and inerrable.
Although previous studies on test smells have presented
valuable suggestions and practical tools, their main focuses
were on detecting and refactoring test smells, and “the changes
in test smell trends” have not been well-analyzed to the bestof our knowledge. For example, suppose the number of test
cases with a speciﬁc test smell tends to increase in a softwaredevelopment project through its code changes (commits on therepository). Such a test smell may keep staying and growing
in the test code as a technical debt for the project without
the developers being aware of it. Hence, we consider thechanges in test smell trends are also worthwhile to analyze forsuccessful technical debt management, and this is our research
motivation in this paper.

III. DATA A NALYSISAs mentioned in Section II, previous studies on test smells
have mainly focused on detecting and refactoring the test
smells but have not analyzed the changes in smell trends well.
Thus, we conducted a large-scale investigation of test smells in
100 Python open-source projects and quantitatively analyzed
their trends over commit histories. We report our investigationand the analysis results in this section.
A. Aim
We tackle the following two research questions (RQs).
RQ1: What test smells will likely appear in Python test
code? Do the trends differ among projects?
• RQ2: How does each test smell’s trend change overcommits? Do the trends differ among projects?
RQ1 is a fundamental question regarding test smells. To
answer RQ1, we collect test smell data from various opensource projects. The investigation results would present basic
data for discussing effective preventive measures against quality deterioration caused by test smells. RQ2 is a further and ourprimary question by introducing a time perspective: although
RQ1 focuses on test smells detected in a snapshot of test code,
RQ2 considers their changes over time (commit histories). As
mentioned above, we will analyze the changes in test smell
trends toward successful technical debt management.
•

TABLE IIR ELATIVE F REQUENCIES OF T EST S MELLS IN A LL P ROJECTS
Rank
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Test Smell
Assertion Roulette
Conditional Test Logic
Magic Number Test
General Fixture
Unknown Test
Duplicate Assertion
Test Maverick
Exception Handling
Lack Cohesion
Suboptimal Assert
Obscure In Line Setup
Redundant Print
Ignored Test
Sleepy Test
Redundant Assertion
Empty Test
Constructor Initialization
Default Test

Relative Frequency
23.6%
13.0%
11.7%
10.1%
8.6%
7.4%
5.0%
5.0%
4.9%
4.7%
1.9%
1.7%
0.9%
0.8%
0.4%
0.2%
0.1%
0.0%

Test smell counts may ﬂuctuate after adding new test code
because some test engineers notice and refactor test smells.
We adopted the moving average method because we aim
to obverse the rough increasing/decreasing trends in commit
histories. We empirically set the window size to 50 to ﬁlter
out short-term ﬂuctuations.
C. Results and Discussions on RQ1

1 The

project list is available from our supplemental data site,
https://se.cite.ehime-u.ac.jp/data/Fushihara SEAA2023/ .

20
15
10

#projects

25

We begin with reporting the results regarding RQ1. Table IIpresents the relative frequencies of test smell appearance
counts in all the latest test programs of all studied projects. The
table shows that “Assertion Roulette” is the most frequently
appearing smell, and “Default Test” did not appear at all. The
distribution of test smells shown in Table II is close to theresults reported in the previous study [5]. The Spearman’s
ρ between our result and the previous one is 0.98, andwe consider that we could replicate the empirical results
successfully.
Next, we compared the test smell distributions among
projects: For each project, we regarded the project’s relative
frequencies of test smells as the 18-dimensional vector andcomputed their cosine similarities. Fig. 2 shows the histogramof cosine similarities; the median and mean values were0.8990 and 0.8287. Hence, we can say that the test smell
distributions are similar among most projects. We also examined six projects with the lowest similarities, i.e., thosewith different smell distributions. As a result, ﬁve out of six

5

We collected test smell data from 100 Python open-source
projects1 , satisfying the following six conditions to examine
active projects [13]: (i) Their “stars” scores are higher than 50;(ii) They have modiﬁed not only production code but test code
through commits; (iii) Their repositories have more than 1000
commits; (iv) They have more than ten contributors; (v) Theirdevelopments have lasted more than two years; (vi) They have
had one or more commits within the last twelve months.
We performed the following steps for each project to collectand analyze test smell data.
(1) Make a list of commits. Clone the Git repository and list
all commits by checking the commit logs.
(2) Detect test smells. Check out each commit from therepository and run PyNose to detect test smells in that versionof the test programs.
(3) Analyze the collected data for answering RQ1. Countthe detected test smells by smell type (see Table I) in the latest
version and compare their appearance patterns among projects.
(4) Analyze the collected data for answering RQ2. Countthe detected test smells by smell type in each version (commit)
and make their moving averages (window size = 50 commits)
to capture their change trends. Then compute the correlation
coefﬁcient (Spearman’s ρ) between the appearance counts
and commit times for each smell type to understand its increasing/decreasing trend. Moreover, compare the correlation
coefﬁcients among projects.

0

B. Studied Projects and Data Analysis Procedure

0.0

0.2

0.4

0.6

0.8

1.0

Cos similarity

Fig. 2. Histogram of cosine similarities among projects.

TABLE III
P ERCENTAGES OF P ROJECTS C ORRESPONDING TO T RENDS OF T EST S MELL C HANGES T HROUGH C OMMITS
ρ < −0.6−0.6 ≤ ρ < −0.2
−0.2 ≤ ρ < 0.2
0.2 ≤ ρ < 0.6
9.2%
10.5%
6.6%
7.9%
7.9%
10.5%
6.6%
10.5%
7.9%
7.9%
7.9%
13.2%
3.9%
15.8%
5.3%
9.2%
7.9%
7.9%
13.2%
14.5%
5.3%
10.5%
5.3%
5.3%
6.6%
13.2%
5.3%
7.9%
7.9%
7.9%
11.8%
11.8%
2.6%
17.1%
10.5%
13.2%
5.3%
10.5%
6.6%
7.9%
3.9%
7.9%
11.8%
10.5%
0.0%
2.6%
11.8%
14.5%
3.9%
2.6%
6.6%
3.9%
2.6%
5.3%
10.5%
10.5%
2.6%
6.6%
13.2%
5.3%
5.3%
3.9%
21.1%
3.9%
1.3%
5.3%
1.3%
3.9%
0.0%
0.0%
1.3%
0.0%
4.7%
8.1%
8.7%
8.6%
(NA: the projects have no test smell corresponding to the row.)

Test Smell
Assertion Roulette
Conditional Test Logic
Magic Number Test
General Fixture
Unknown Test
Duplicate Assertion
Test Maverick
Exception Handling
Lack Cohesion
Suboptimal Assert
Obscure In Line Setup
Redundant Print
Ignored Test
Sleepy Test
Redundant Assertion
Empty Test
Constructor Initialization
Default Test
Average

projects (workload-automation, scvi-tools, pudb, rosdistro, andmagic-wormhole) had fewer test smells, which may be the reason why they showed dissimilar distributions. The remaining
project—remi—had a project-speciﬁc trend: “General Fixture”
appeared three times as many as “Assertion Roulette.” No
other projects showed such a project-speciﬁc difference.
From the above results, we answer RQ1 as follows. The
most frequently appearing (top 3) test smells in Python would
be “Assertion Roulette,” “Conditional Test Logic,” and “Magic
Number Test,” and they share about half of all test smells.
The trend of test smell seems to be common to most projects.
Because these smells are related to how to write assertions or
issues on test code readability, it is efﬁcient to consider thepreventive measures for them to control technical debt.
D. Results and Discussions on RQ2

30

Number of detected test smells

Number of detected test smells

We focused on the changes in test smell appearances overcommits and collected the trend data (moving averages) fromthe studied projects. Fig. 3 presents the changing trends of“Assertion Roulette” in pyinfra and ibis projects. While we
can see a monotonically increasing trend of the test smell overcommits in pyinfra project (see Fig. 3(a)), we also observe an
opposite trend in ibis project (see Fig. 3(b)). We obtained those

25

20

15

10

5

0
0

500

1000

1500

2000

2500

Number of commits(a) pyinfra

3000

3500

50

40

30

20

10

0
0

500

1000

1500

2000

2500

3000

3500

ρ ≥ 0.6
57.9%
56.6%
46.1%
47.4%
44.7%
55.3%
43.4%
38.2%
39.5%
43.4%
22.4%
22.4%
15.8%
15.8%
14.5%
11.8%
2.6%
0.0%
32.1%

NA
7.9%
7.9%
17.1%
18.4%
11.8%
18.4%
23.7%
22.4%
17.1%
26.3%
43.4%
48.7%
67.1%
55.3%
57.9%
53.9%
85.5%
98.7%
37.9%

trend data for all combinations of the available test smells
and the studied projects. Then we computed Spearman’s ρ tocapture their increasing/decreasing trends quantitatively. For
instance, we obtained ρ = 0.995 and ρ = −0.899 for thetrend data of “Assertion Roulette” in pyinfra and ibis projects(Fig. 3(a) and (b)), respectively; these correlation coefﬁcients
indicate a strong increasing trend and a strong decreasing
one. Table III presents the results of all test smells. In thetable, the highest percentage within a test smell (a row) isemphasized by boldface. For example, “Assertion Roulette”
had a strong increasing trend (ρ ≥ 0.6) in 57.8% of projects2 .
On the other hand, there are also projects having decreasing
trends of test smells (ρ < −0.2), although they are a minority(4.7 + 8.1 = 12.8%). We can see that the highest percentage
categories of projects are “ρ > 0.6,” i.e., increasing trends
for the most appearing ten kinds of test smells—Assertion
Roulette, Conditional Test Logic, . . . , Suboptimal Assert—inTable III. Although the remaining eight kinds of test smells
tend not to appear in projects, six out of eight showed that“ρ > 0.6” are the highest percentage categories within the
projects where those smells appeared. Hence, we can say most
test smells tend to increase over commits. It would be adequate
to detect and refactor those frequently appearing test smells
as early as possible to avoid the risk of performing unreliable
tests.
Interestingly, 7.9–9.2% of projects also had decreasing
trends (ρ < 0.6) for the most appearing three kinds oftest smells—Assertion Roulette, Conditional Test Logic, andMagic Number Test. Although those projects are the minority,some developers or test engineers of the projects might pay
attention to test smells. On average, while 40.7% (= 8.6% +32.1%) of projects showed increasing trends of test smells,

Number of commits(b) ibis

Fig. 3. Change trends of number of detected test smells corresponding to“Assertion Roulette” in pyinfra and ibis projects.

2 Since no test smell was detected by PyNose throughout the commits in
24 out of 100 projects, the presented values are the percentages in the 76
projects where at least one test smell had appeared.

12.8% of projects had decreasing trends, so that the test smellchanging trend may differ among projects.
From the above results, we answer RQ2 as follows. Test
smells tend to increase through commits in Python projects.
The potential risks caused by test smells would grow without
preventive measures, and it is vital to detect and resolve test
smells as early as possible. Although those trends may differ
among projects, the most frequently appearing ten kinds oftest smells have increasing trends in 39.5–57.9% of the studied
projects.
Notice that the above analysis has focused on the numberof detected test smells but not their ratios to the number oftest cases or the lines of test code. In this study, we have paid
attention to the existence of test smells because their presence
can cause a risk of unreliable tests. On the other hand, it would
also be worthwhile to analyze “the rate” of each kind of test
smells in a project, like a bug (fault) rate discussed in the faultprone module analysis studies, because the test code would
also evolve with the production code through commits. We
plan to do a further analysis focusing on the test smell rate
to obtain a deeper insight into the test smell trends as oursigniﬁcant future work.
E. Threats to Validity
We empirically set the window size of the moving average
to 50 in our data analysis. Since a different window size canpresent a different trend data of test smell, the window size
selection can threaten our construct validity. Although we haveused the window size to ﬁlter out short-term ﬂuctuations, itwould be better to utilize an advanced time series analysis
method for mitigating the threat, and we also plan to perform
it in our future work.
Another threat to our construct validity is the test smell
detection tool we used in this study because we have used only
the PyNose to detect smells. There might be a tool-speciﬁc
potential bias in the test smell detection. For example, there
might be a kind of test smells that PyNose is likely to miss,but another tool can detect it. We also need to use other stateof-the-art tools [14] to mitigate the threat for further smell
data analysis.
Our data analysis results are derived from only Python opensource projects, which can threaten the external validity ofthis study. Although we can expect that similar trends of test
smells may be observed in other language projects because theconcept of unit testing is common to other languages, we needto conduct further data collection and analysis to generalize
our results to test programs in other languages.
IV. C ONCLUSION AND F UTURE W ORK
We have focused on “test smells,” i.e., code smells in test
code, which may adversely affect both production and test
code. Although the previous studies presented valuable test
smell detection and refactoring methods, they missed analysisof their changing trends through commits. In this paper, weinvestigated 100 open-source Python projects and analyzed
trend data of test smells. As a result, we obtained the following

ﬁndings: (1) a few kinds of test smells—Assertion Roulette,
Conditional Test Logic, and Magic Number Test—constitutethe majority of smells detected in the studied projects, and (2)most kinds of smells tend to increase over commits, i.e., many
test smells are likely to have remained in test code as technicaldebt. Since developers and test engineers may overlook thosekinds of test smells, detecting and refactoring them as earlyas possible is helpful for successful test code management.
In particular, detecting the above frequently appearing smells
and giving a warning to test engineers would be an efﬁcient
preventive measure against test-related technical debt.
Our future work includes (i) detailed analyses of whatcauses the test smell growth and of how the test smell growthaffects the quality of production code; (ii) an analysis ofhuman aspects of the test smells, e.g., on the question “Is atest smell speciﬁc to a particular test engineer?”; (iii) further
data analysis using another state-of-the-art detection tool [14]that can detect other kinds of test smells, such as the “Rotten
Green Test.”
ACKNOWLEDGMENT
This work was supported by JSPS KAKENHI #20H04184,#21K11831, #21K11833, and #23K11382.
R EFERENCES[1] G. Meszaros, xUnit Test Patterns: Refactoring Test Code. Boston, MA:
Addison-Wesley Professional, 2007.
[2] A. Zaidman, B. Van Rompaey, S. Demeyer, and A. van Deursen,“Mining software repositories to study co-evolution of production &test code,” in Proc. 1st Int. Conf. Softw. Testing, V. & V., Apr. 2008, pp.
220–229.
[3] M. Fowler, Refactoring: Improving the Design of Existing Code.
Boston, MA, USA: Addison-Wesley, 1999.
[4] A. V. Deursen, L. Moonen, A. Bergh, and G. Kok, “Refactoring
test code,” in Proc. 2nd Int. Conf. Extreme Programming & Flexible
Processes in Softw. Eng., May 2001, pp. 92–95.
[5] T. Wang, Y. Golubev, O. Smirnov, J. Li, T. Bryksin, and I. Ahmed,“Pynose: A test smell detector for python,” in Proc. 36th Int. Conf.
Automated Softw. Eng., Nov. 2021, pp. 593–605.
[6] C. Jones, Applied Software Measurement: Global Analysis of Productivity and Quality, 3rd ed. New York: McGraw-Hill, 2008.
[7] M. Greiler, A. Van Deursen, and M.-A. Storey, “Automated detection oftest ﬁxture strategies and smells,” in Proc. 6th Int. Conf. Softw. Testing,V. & V., Mar. 2013, pp. 322–331.
[8] D. Spadini, F. Palomba, A. Zaidman, M. Bruntink, and A. Bacchelli,“On the relation of test smells to software code quality,” in Proc. Int.
Conf. Softw. Maintenance & Evolution, Sep. 2018, pp. 1–12.
[9] A. Peruma, K. S. Almalki, C. D. Newman, M. W. Mkaouer, A. Ouni, and
F. Palomba, “On the distribution of test smells in open source android
applications: An exploratory study,” in Proc. 29th Int. Conf. Comp. Sc.
& Softw. Eng., Nov. 2019, pp. 193–202.
[10] A. Peruma, K. Almalki, C. D. Newman, M. W. Mkaouer, A. Ouni,
and F. Palomba, “tsDetect: an open source test smells detection tool,”in Proc. 28th Joint European Softw. Eng. Conf. & Symp. Foundations
Softw. Eng., Nov. 2020, pp. 1650–1654.
[11] S. Lambiase, A. Cupito, F. Pecorelli, A. De Lucia, and F. Palomba,“Just-in-time test smell detection and refactoring: The darts project,” inProc. 28th Int. Conf. Program Comprehension, May 2020, pp. 441–445.
[12] T. Virgı́nio, L. Martins, L. Rocha, R. Santana, A. Cruz, H. Costa, andI. Machado, “Jnose: Java test smell detector,” in Proc. 34th Brazilian
Symp. Softw. Eng., Oct. 2020, pp. 564–569.
[13] E. Kalliamvakou, G. Gousios, K. Blincoe, L. Singer, D. M. German,
and D. Damian, “The promises and perils of mining github,” in Proc.
11th Working Conf. Mining Softw. Repositories, May 2014, pp. 92–101.
[14] F. Maier and M. Felderer, “Detection of test smells with basic language
analysis methods and its evaluation,” in Proc. IEEE Int. Conf. Softw.
Analysis, Evolution & Reeng., Mar. 2023, pp. 897–904.