50
特集●ソフトウェア論文

JTDog:
動的テストスメル検出のための Gradle プラグイン
谷口 真幸

柗本 真佑 楠本 真二

テストコードの可読性や保守性に対する潜在的な問題を表す概念として，テストスメルが知られている．一般的なテストスメルはテストの長さや複雑さといったソースコードの静的な側面に着目しており，検出が容易な一方で常に問題につながるとは限らない．他方，テスト実行時の振る舞いに基づく動的スメルは，テストの実施が不十分であるのに，問題なくテストが成功したという誤った認識を開発者に与えるなど，テスト結果の誤解につながることが多い．
そのため，可能な限り早期に検出し対策することが望ましい．本論文では，動的スメルの検出を行う Gradle プラグインである JTDog を提案する．ビルドツールへの組み込みにより，JTDog は高い可搬性を有している．GitHub
上の 205 のプロジェクトに対する適用実験の結果，JTDog の可搬性を確認することができた．また，実際に 66 のプロジェクトから 1,117 個の動的スメルを検出できた．

The concept of the test smell represents potential problems with the readability and maintainability of thetest code. Common test smells focus on static aspects of the source code, such as code length and complexity.
These are easy to detect and do not cause problems in terms of test execution. On the other hand, dynamic
smells, which are based on test runtime behavior, lead to misunderstanding of the test results. For example,
they give developers the false impression that the test was passed without any problems, even though thetest was poorly executed. Therefore, we should detect dynamic smells and take countermeasures as early as
possible through the development. In this paper, we propose JTDog, a Gradle plugin for detecting dynamic
smells. JTDog has high portability due to its integration into the build tool. We applied JTDog to 205
projects on GitHub and conﬁrmed that the JTDog plugin has high portability. In addition, JTDog detected
1,117 dynamic smells in 66 projects.

メルとして，長すぎるコードや重複したテストが知ら

1 はじめにれている [20]．これらのスメルがプロダクトコード

プロダクトコードにおけるコードスメルと同様，テでも共通する潜在的問題であるのに対し，テストコー

ストコードにおける設計上の問題を示す指標としてテド固有のスメルも存在する．例えば，テストコード内

ストスメルが知られている [10]．テストスメルは可での制御文の使用箇所は一種のスメルと見なされる．

読性や保守性などに対する潜在的な問題を示唆して

制御文はテストの複雑化を招くうえ，テストコード自おり，テスト品質の低下につながる恐れがある．その体のバグにつながる可能性があるためである [20]．

ため，早期に検出しリファクタリングなどのコード改これら一般的なテストスメルはテストコードの静善によって排除されることが望ましい．代表的なス的な側面に着目しており，その悪影響の対象も保守性などの静的な観点に限定される．以降，本論文ではこJTDog: a Gradle Plugin for Detecting Dynamic Test
Smells
Masayuki Taniguchi, Shinsuke Matsumoto, Shinji
Kusumoto, 大阪大学大学院情報科学研究科, Graduate School of Information Science and Technology,
Osaka University.
コンピュータソフトウェア, Vol.39, No.4 (2022), pp.50–60.
[ソフトウェア論文] 2021 年 11 月 29 日受付.

れらのスメルを静的スメルと呼ぶ．例えば先の例に挙げた，長すぎるテストコードは，理解の困難さや保守コストの増大などにつながる問題ではあるものの，
テスト実行結果への影響はない．制御文を含むテス
トコードも同様に，テストの複雑さやテスト自体のバ
グにつながる潜在的な問題を示しているが，テスト実

Vol. 39 No. 4 Nov. 2022
行という側面での問題にはならない．
その一方で，テストの実行結果に影響を与えるスメ

51

し，そのうち 66 のプロジェクトから合計 1,117 個の動的スメルを検出できた．

Green Test [9] は，成功したテストのうち，未実行のJTDog は GitHub 上 で OSS と し て 開 発 し て お
り †1 ，プラグイン自体も Gradle Plugin Portal で公アサーションを含むテストのことであり，当該アサー開している †2 ．

ル（以降，動的スメル）も存在する．例えば Rotten

ションによる動作確認が不十分であるにも関わらず，開発者にテストが問題なく成功したという誤った認

2 動的スメル検出の自動化

識を与えてしまう．このように，動的スメルはテスト

本章では，まず具体的な動的スメルの特徴と及ぼすの実行結果に関する問題を引き起こし，テスト結果の影響について紹介する．さらに複数種の動的スメル

誤解につながるため，テストの品質に重大な影響を及検出ツールの設計にあたっての課題と問題点についぼす．また，動的スメルを検出するためには，実行時て議論する．

解析のために対象プロジェクトの実行情報（クラス
ファイルや外部ライブラリへのパスなど）の明示的な

2. 1 動的スメル指定が必要となる．そのため，素朴な設計の動的スメ

動的スメルは，テスト実行の経路，順序，結果な

ル検出ツールは環境と密に結合し，可搬性が低くなる

ど，テスト実行時の振る舞いに基づいたスメルであ傾向にある．

る．動的スメルの一種として，開発者に十分にテスト

これまでに数多くのテストスメルに関する研しているという印象を与えながら，実際にはほとんど

究 [2, 3, 24, 26] が実施されており，TestQ [7] や tsDe-

バグを検出できないようなパターンも知られており，

tect [25] など，複数種のテストスメル検出を目的とテストの品質に重大な影響を及ぼすことがある．動したツールが多く提案されている．しかし，これらの的スメルを検出するためには，実行時解析のために対ツールが検出可能なスメルはすべて静的スメルに限

象プロジェクトの実行情報（クラスファイルや外部定される．さらに，動的スメルを検出するツールも提ライブラリへのパスなど）の明示的な指定が必要と案されているが [5, 19, 28]，いずれも単一の動的スメなる．そのため，素朴な設計の動的スメル検出ツー

ルを対象としており，我々の知る限り，複数種の動的

ルは環境と密に結合し，可搬性が低くなる傾向にあ

スメルをまとめて検出するツールは存在しない．

る．現状，Rotten Green Test [9]，Flaky Test [18]，

本論文では，高い可搬性を有し，同時に複数種の動Dependent Test [28] の 3 種が存在する．

的スメルの検出が可能である動的スメル検出ツール

2. 1. 1 Rotten Green Test

JTDog を提案する．JTDog はビルドツールである

Rotten Green Test は，成功したテストのうち，未Gradle のプラグインとして組み込んだため，Gradle

実行のアサーションを含むテストのことである．テスを利用するプロジェクトであれば容易に適用できる高トはプロダクトコードの実行と動作確認という 2 つ

い可搬性を有している．また，JTDog は単一コマンの要素で構成される．プロダクトコードの実行はプドで即座に実行可能であるため，CI（継続的インテグ

ロダクトクラスやメソッドを呼び出す系列の部分でレーション）のような自動化技術との親和性も高い．

あり，動作確認はアサーションなどの命令を用いてJTDog は 3 つの動的スメル Rotten Green Test [9]，実行時の動作が期待通りであるかを確認する部分でFlaky Test [18]，Dependent Test [28] を検出する．

ある．Rotten Green Test は，未実行のアサーション

1 つのツールで同時に複数種の動的スメルを検出するによる動作確認が一切行われていないにも関わらず，ことができるため，開発者の生産性向上につながる．

常に成功したテストとして報告される．例えば図 1

JTDog の可搬性を確かめるため，GitHub 上の 205のプロジェクトに対して適用実験を行った．その結果，171 のプロジェクトでプラグインが正常に動作†1 https://plugins.gradle.org/plugin/com.github.
m-tanigt.jtdog†2 https://github.com/kusumotolab/JTDog

コンピュータソフトウェア

52
1
2
3
4
5
6
7
8
9

// 誤 っ た テ ス ト デ ー タ
URL data = getResource ( " testData . xml " ) ;DataBase db = new DataBase ( data ) ;// 実 際 は 空 の リ ス ト
List < User > users = db . getUsers () ;for ( User user : users ) {// 実 行 さ れ な い
assertNotNull(user.getName());}

2. 2 既存のテストスメル検出ツールの問題点
テストスメルに関しては多くの既存研究が存在しており [2, 3, 24, 26]，これまでに様々な検出手法や検出ツールが提案されている．しかし，動的スメルの検出に焦点を当てると，既存のテストスメル検出ツールには問題がある．

図1

Rotten Green Test の例

まず，既存の動的スメル検出ツール [5, 19, 28] は利用のための環境設定が煩雑である．動的スメル検出

は，アサーションにより，リスト中の各ユーザの名前には実行時解析が必要であり，ツール利用のために対が null でないかを確認するテストである．しかし，

象プロジェクトの実行情報（クラスファイルや外部ラ

2 行目のテストデータが誤っており，5 行目で取得すイブラリへのパスなど）の明示的な指定が必要なたるリストが空となるため，for 文内の処理が実行されめである．これら実行情報の継続的な保守はソフト

ず，8 行目のアサーションは実行されない．

ウェア進化における必須工程の一つであり，環境設定

また，Rotten Green Test は，本質的でないテストの煩雑さは動的スメル検出ツールの利用を阻害する

成功数の増加や無意味なカバレッジの増加といった要因となりうる．ひいてはソフトウェア全体の品質問題も引き起こす．そのため，テストの実施が不十分

低下につながる可能性がある．

であるにも関わらず，開発者にテストは問題なく成功したという誤った認識を与えてしまう．

さらに，複数種の動的スメルを一度に検出可能なツールは存在しないという問題もある．複数種のテ

2. 1. 2 Flaky Test

ストスメル検出を目的としたツールは TestQ [7] やFlaky Test は，同じコード，同じ実行環境である

tsDetect [25] などが存在するが，どちらも静的スメにも関わらず，実行するたびにテストの成否が変化す

ルの検出に限定されている．また動的スメルがテストるテストである．通常，開発者はテスト結果が変化し実行を必要とする性質から，これら既存ツールの動的た原因をテストコードや実行環境の変更によるもの

スメル検出への拡張は容易とはいえない．動的スメルと考えるため，Flaky Test による変化であることをの検出という観点では，RTj [19] や DTDetector [28]特定するためだけに，多大な時間や労力を費やすことが存在するが，それぞれ単一の動的スメル検出を目的となる．また，Flaky Test による失敗が頻繁に発生としている．よって，3 種の動的スメルをすべて検出する場合，開発者はその失敗を無視する傾向があるたするために既存の動的スメル検出ツールを利用する

め，バグを見逃すきっかけともなる [18]．

場合，それぞれのツールについて煩雑な環境設定が必

2. 1. 3 Dependent Test

要なため，開発者の生産性低下，もしくはテスト品質

Dependent Test は，テストの実行順序が変わるとの低下につながる恐れがある．

テスト結果が変わってしまうような，テスト間に存在する依存関係に基づくスメルである．

3 JTDog

テスト順序の変更によりテストが失敗した場合，多JTDog は，Java プロジェクトを対象とした動的なくの場合はテスト実行前の初期化処理の失敗が原因でテストスメル検出のための Gradle プラグインである．

ある．しかし，開発者が Dependent Test を知らない

Gradle への組み込みにより，高い可搬性を有してい場合，原因の特定は困難であり，開発者は Dependent

る．単一コマンドで実行可能であるため，CI のよう

Test のテスト対象のプロダクトコードがバグを含むな自動化技術とも親和性が高い．JTDog は，3 種類のと判断してしまう恐れがある．また，テスト順序の変動的スメル Rotten Green Test [9]，Flaky Test [18]，

更によるテスト結果の変化は，通常の実行順序では表

Dependent Test [28] を検出し，その結果を JSON

面化しないバグを見逃すきっかけとなる [28]．

ファイルに出力する．高可搬性の実現によって利用

Vol. 39 No. 4 Nov. 2022
が容易であるうえ，テストの品質に重大な影響を及ぼす動的スメルをまとめて検出できるため，JTDog は開発者の生産性向上に寄与する．

53

法がある [5, 14]．

JTDog は，テストを複数回再実行することでFlaky Test の検出を行う．
一般的には，テストの再実行による検出では失敗

3. 1 使用方法

テストのみが再実行されることが多い [18]．こJTDog の利用に当たっては，まず開発者はビル

れは，検出のためのテスト実行コストを低減す

ドファイルである build.gradle 内に以下のようにるためである．例えば Google では，Flaky Test

JTDog の利用を宣言する．

検出のためのコストを最小化するために，失敗テ

plugins {id ’ com . github .m - tanigt . jtdog ’ version ’ latest ’}

この宣言により，動的スメルを検出する sniff という名称の Gradle タスクが提供される．プロジェクトの実行情報は build.gradle 内に記述されているため，JTDog はその内容を自動的に読み取り，コンパ
イルやテスト実行などの動的スメル検出に必要な処理を実行する．開発者は gradle sniff というコマ
ンドを 1 行実行するだけでプロジェクトに存在する
動的スメルの検出が可能である．

3. 2 設計
3. 2. 1 動的スメルの検出
JTDog は 3 つの動的スメル Rotten Green Test [9],Flaky Test [18], Dependent Test [28] を検出する．
これら複数種の動的スメルを単一ツールで検出することで，動的スメル検出にかかる労力の削減を狙う．
本項では，各スメルの検出手法を示す．

Rotten Green Test Delplanque ら [9] の手法に従って Rotten Green Test の検出を行う．まず，テストコードを静的解析し，各メソッドが持つ要素（アサーションやメソッド呼び出しなど）を調べる．そして，各テストを実行し，成功した
場合にカバレッジデータの解析を行い，テストが未実行のアサーションを含むかを確認する．

Flaky Test Flaky Test の検出手法は近年数多く提案されている．最も単純な手法としては，テス
トを複数回再実行し，その成否が安定するか調べるという手法が挙げられる [18]．その他，コード変更によるカバレッジの変化を監視する方法や，機械学習を用いて失敗したテストを分類する方

ストのみを再実行の対象としたうえで，さらにその中で問題があると思われるテストのみを再実行している [21, 22]．本研究では正確な Flaky

Test 検出のために，失敗テストだけでなく成功
テストも再実行する．
テストの再実行回数はデフォルトで 10 回であり，

JTDog の利用者による変更も可能である．この10 回という値は既存の Flaky Test 検出研究 [18]を参考にした．

Dependent Test Dependent Test は，1 度通常の順序でテストを実行した後，テスト順序を，逆順にする，ランダムに入れ替えるなどして再実行
し，テスト結果が通常の順序の場合と異なるかを調べるという検出方法が知られている [28]．本
研究では，ランダムな順序で複数回再実行することで Dependent Test の検出を行う．Flaky Testの検出と同様，テストの再実行回数はデフォルト
で 10 回で，JTDog の利用者により変更できる．

3. 2. 2 ワークフロー
前項に示した検出手法を用いて，以下の手順で動的
スメルの検出を行う．

1. テストコードを静的解析し，メソッド情報を収集する．

2. テストクラスのバイトコードにカバレッジ計測
命令を埋め込む．

3. 通常の順序で各改変済みテストを実行する．
4. 成功したテストについて，計測した実行経路情報を用いて未実行アサーションの有無を調べ，

Rotten Green Test か否かを判別する．
5. テストを通常の順序で複数回再実行し，テスト結果に変化が生じるかを調べ，Flaky Test を検出する．

コンピュータソフトウェア

54

6. 通常の順序でのテスト実行終了後，ランダムに

JTDog Plugin

順序を変更してテスト実行を行い，Dependent

sniff

Test を検出する．

ユーザ

1. 実行

3. 3. 1 動的スメルの検出
JSON利用してテストコードの AST を生成し，これを解析

2. 実行

3. コンパイル

5. 動的スメル検出- Rotten Green Test (- Flaky Test ( )- Dependent Test ( )タスク

してメソッド情報を収集する．その後，JaCoCo を用いてテストクラスのバイトコードにカバレッジ計

testClasses

4. SourceSetの取得

3. 3 実装
動的スメルの検出のため，まず，Eclipse JDT を

Gradle Java Plugin

図2

テスト実行

AST 解析

SourceSet

ソースファイル) テストファイル
クラスファイル
クラスパス …
カバレッジ解析

Gradle API を利用した検出処理の概要

測命令を埋め込み，JUnit を用いて通常の順序でテストを実行する．そして，成功したテストについて，

3. 3. 2 Gradle の利用

Rotten Green Test であるかを調べる．事前に収集

前述の動的スメルの検出処理を行うためには，プロしたメソッド情報から該当テストメソッドが含むア

ダクトコードやテストコードに加え，クラスファイル

サーションの行番号を取得し，その行の命令が実行さや外部ライブラリのパスなど様々な情報が必要であれているかをカバレッジデータから取得することで，る．ビルドツールである Gradle はソースフォルダの未実行のアサーションを含むかを判断できる．なお，管理や依存関係の解決などを自動で行うことが可能

テストがメソッド呼び出しを含む場合，そのメソッド

なため，動的スメル検出技術を Gradle へ組み込むこについても再帰的に未実行のアサーションを含むかとで，実行に必要なすべての情報を Gradle から取得を調べる．

でき，高い可搬性を実現できる．

次に，通常の順序でテストを再実行するという処

図 2 に Gradle API を利用した検出処理の概要を

理を複数回行う．この再実行において 1 度でもテ示す． Gradle を利用した Java プロジェクトでは，

スト結果に変化が生じた場合，当該テストが FlakyJava のコンパイルやテストを行うために Java プラ

Test と判断できる．なお，テスト実行はそれぞれ別

グインを適用する．JTDog が提供する sniff タスク

JVM 上で実施する．これは，同一 JVM 上で再実行

は，Java プラグインが提供する testClasses タスク

する場合，複数テスト間での static 変数の共有に起因に依存している．これにより，sniff タスクを実行する Dependent Test など，JVM の状態に依存するする際，先に testClasses タスクが実行され，Java

Dependent Test のテスト結果に変化が生じ，Flaky

ファイルのコンパイルなどの前処理が行われる．

Test として誤検出する恐れがあるためである．

また，Java プラグインはソースセットをプロジェ

通常の順序でのテスト実行終了後，順序をランダムクトに導入する．ソースセットとは，ソースおよびに入れ替えてのテスト実行を複数回行う．Flaky Test

リソースファイルのコンパイルに関する情報を結びの検出と同様，テスト実行はそれぞれ別 JVM 上で実つける概念である．ソースセットを利用することで，施する．各テストメソッドについて，テスト結果を

ソースファイルやクラスファイル，クラスパスなどを通常のテスト実行時の結果と比較し，異なる場合に取得することができる．JTDog はまず，ソースセッ

Dependent Test と判断する．ただし，このテストがトからプロダクトコードとテストコードを取得し，テ

既に Flaky Test として判定されている場合は，順序

ストコードの抽象構文木を生成および解析することに依存せずにテスト結果が変わるため，Dependent

でメソッドの情報を収集する．そして，ソースセッ

Test ではないと判断する．

トからテストクラスファイルとクラスパスを取得し，テストの改変と実行を行うことでテスト結果やカバ
レッジデータを取得する．これらのデータを合わせ

Vol. 39 No. 4 Nov. 2022
ることで，動的スメルを検出することができる．

55

る 171 のプロジェクトで正常に動作した．プラグイ
ン利用のための一文を追加するのみで動作しており，

4 適用実験

JTDog は様々なプロジェクトに適用可能であるとい

JTDog の可搬性及び動的スメル検出能力の確認をえる．

目的として，GitHub 上の Gradle プロジェクトに対する適用実験を行う．

適用に失敗した 34 のプロジェクトの失敗原因を目視により確認した．その内訳を表 1 に示す． 表 1 の
うち，メモリ不足による失敗の理由を調べたところ，

4. 1 適用対象

プロジェクトのメソッド数が膨大であることが原因

GitHub 上のプロジェクトから，以下を満たすプロであった．前述の通り，本実験では JVM の最大ヒージェクトを選択した．

プサイズを Gradle の標準設定よりも大きい 2048MB• ビルドツールとして Gradle を使用している，としたが，それにもかかわらずヒープ領域のメモリ不あるいは，Gradle の変換機能により問題なく足が発生した．この事実と，JTDog が動的スメル検

Gradle プロジェクトに変換可能な Maven プロ

出の際にメソッド情報を収集・保持し，メソッド数がジェクトである．

多いほど情報保持のためにメモリを使用することを• 主要言語が Java であり，Gradle の Java プラグ

考えると，現在の実装では非常に大規模なプロジェク

インを適用している．

トへの JTDog の適用は難しいと考えられる．メモリ• テストを 1 つ以上含む．

不足以外の原因については，現状，その理由は把握し• テストフレームワークに JUnit を用いている．

きれておらず，今後の詳細な分析が必要である．

上記の条件に加えて，一定以上の人気があるプロ

4. 3. 2 動的スメルの検出結果

ジェクトに絞るため，Star が 100 以上であるプロジェ

まず，JTDog が正常に動作した 171 のプロジェク

クトに限定した．以上の条件に基づき，205 のプロ

トでの動的スメル検出数とスメルを検出したプロジェ

ジェクトを適用対象プロジェクトとして選択した．

クトの数を表 2 に示す． この結果より，適用に成功した 171 のプロジェクトのうち 66 件で動的スメルを

4. 2 実験方法

検出したことがわかる．そして，検出した 3 種の動適用対象の各プロジェクトについて，3. 1 節で示し

表1

たように JTDog の利用宣言文を build.gradle ファ

JTDog 適用失敗の原因

適用失敗の原因

イルに追記する．そして，sniff タスクを実行し，プロジェクト数

検出結果が出力された JSON ファイルの内容を確認

タスク作成失敗

10

する．

メモリ不足

9

検出結果が不正6

準で 1024MB としているが，本実験では 2048MB と静的/動的解析が実行されない6

した．これは，非常に大規模なビルドの場合，Gradle

ファイル読み込み失敗

3

なお，Gradle では JVM の最大ヒープサイズを標のシステム動作のためにより大きなメモリが必要な
表2

場合があり，本実験では様々な規模の OSS を対象と

動的スメル検出結果

検出数

プロジェクト数

Rotten Green Test

806

55

4. 3 実験結果

Flaky Test

181

10

4. 3. 1 可搬性の確認

Dependent Test

130

14

適用対象として選択した 205 のプロジェクトに対

合計

1,117

66

するためである．

して JTDog を適用した結果，そのおよそ 83%であコンピュータソフトウェア

56

的スメルについて，それぞれサンプリングし，動的

表 5 の Dependent Test 検出数上位 5 件のプロジェ

スメルであることを目視で確認したため，JTDog はクトに関して，いずれのプロジェクトにおいても，テ動的スメル検出能力を十分有していると言える．まスト間で static 変数を共有することが主な原因でた，Rotten Green Test は Flaky Test や Dependent

あった．このようなテストは，同じ static 変数を使

Test と比べ，スメル検出数，検出プロジェクト数のい用するテストの追加などに影響を受け，テスト結果がずれにおいても多い結果となった．これは，Rotten

変わる可能性がある．よって，Dependent Test は早Green Test が 2019 年に発表された論文 [9] で紹介さ期に検出し対策することが望ましく，JTDog のようれた新しいスメルであり，その存在が周知されていな検出ツールは重要であるといえる．

ないことが原因の一つであると考えられる．Rotten

Green Test は，テストの実施が不十分であるにも関4. 4 動的スメルの検出例

わらず開発者にテストが問題なく成功したという誤っ

本節では，JTDog が検出した各動的スメルの実例た認識を与えるため，まったくテストをしないよりもを紹介する．

悪質である [9]．ゆえに，Rotten Green Test の検出4. 4. 1 Rotten Green Test

が可能なツールは重要である．

図 3 に示す RxJavaInterop プロジェクトのテスト

次に，プロジェクトごとの各スメルの傾向を調べ

メソッド c1c3IsDisposed() は，JTDog が実際に検る．表 3，4，5 に，それぞれのプロジェクトでの各動出した Rotten Green Test である．イベントリスナ

的スメルの検出数について，スメル検出数上位 5 件ののアクションである onSubscribe() メソッド（437

プロジェクトを抜粋して示す．Rotten Green Test に行目）は内部にアサーションを持つが，このメソッド

ついて，表 3 に示す検出数の多いプロジェクトは，同は実行されない．そのため，439 行目のアサーション

じ原因のスメルを多く含んでいた．例えば検出数が最による動作確認が行われず，テストの実施は不十分でも多い traccar プロジェクトでは，224 個もの Rottenある．このようなコールバック処理は，単純な手続き

Green Test のほとんどは if 文内のアサーションが実行されないことによるものであった．JTDog を使用

表4

Flaky Test 検出プロジェクト

すれば，開発者はどのようなコードが Rotten Green

プロジェクト名

Test であるかを知ることができ，今後の開発に役立

SonarSource/sonarlint-intellij

てることができる．
表 4 の Flaky Test の検出数について，http-request
プロジェクトでの検出数が突出しているものの，それ以外のプロジェクトではほとんど検出されなかった．

検出数

162

cc-tweaked/CC-Tweaked5

auth0/java-jwt

4

ZZMarquis/gmhelper3bulldog2011/bigqueue2

これは，JTDog がテストの再実行という最も単純な検出手法を採用しているためと考えられる．
表3

Rotten Green Test 検出プロジェクト

プロジェクト名

検出数

traccar/traccar

224

elki-project/elki

110

iBotPeaches/Apktool

58

nats-io/nats.java

50

JetBrains/xodius

39

表5

Dependent Test 検出プロジェクト

プロジェクト名

検出数

ehcache/ehcache3

57

kevinsawicki/http-request

28

quicktheories/QuickTheories

12

micrometer-metrics/micrometer11

baomidou/mybatis-plus

6Vol. 39 No. 4 Nov. 2022

432
433
434
435
436
437
438
439
440
441
442
443

@Test
public void c1c3IsDispos ed () {toV3Completable ( Completable . complete () ). subscribe ( new Co m p l e t a b l e O b s e r v er () {@Override
public void onSubscribe ( Disposable d ) {// 実 行 さ れ な い
assertFalse(d.isDisposed());
}
...
}) ;
}

84
85
86
87
88

検出した Rotten Green Test の例 †3@Testpublic void s h o u l d P a s s H M A C 2 5 6 V e r i f i c a t i o n ()throws Exception {Algorithm algorithm = HMAC256 ( " secret " ) ;JWTVerifier verifier = ...;
String token = ...;

89

concurrentVerify(verifier, token);

90
91

}

92
93
94
95

図3

57

96
97
98
99

@ S u p pr ess Wa r n in gs ( " Convert2Lambda " )private void co ncurrentVerify (...) throws
Exception {final Waiter waiter = new Waiter () ;List < VerifyTask > tasks = ...;
executor . invokeAll ( tasks , TIMEOUT , ...) ;waiter . await ( TIMEOUT , REPEAT_COUNT ) ;}的な記述と比べて実際に呼び出されるかどうかの判断が難しく，Rotten Green Test となる可能性が高いと

図4検出した Flaky Test の例 †4

考えられる．JTDog は，こういったコードレビュー
では気づきにくい問題の検出を支援する．
14

4. 4. 2 Flaky Test
図 4 に 示 す java-jwt プ ロ ジ ェ ク ト の テ ス ト
メ ソ ッ ド shouldPassHMAC256Verification() は ，Flaky Test で あ る ．concurrentVerify() メ ソ ッド（93 行目）内でマルチスレッド処理を行う際にRejectedExecutionException という例外が発生してテストが失敗する場合がある．この例外は，マルチ
スレッド処理において各タスクを実行する Thread-

15
16
17
18
19

@Test
public void g e t Cu r re n tU s er n am e () {Se cu r it yC ontext securityContext = ...;
se cu r it yC ontext . setAuth ( " admin " , " admin " ) ;S e c u r i t y C o n t e x t H o l d e r . setContext (...) ;String username = g e tC u rr e nt U se r na m e () ;20

assertThat ( username ) . contains ( " admin " ) ;

21
22

}

23
24
25
26

@Test
public void g e t C u r r e n t U s e r n a m e F o r N o A u t h () {String username = g e tC u rr e nt U se r na m e () ;27

assertThat(username).isEmpty();

28
29

}

PoolExecutor が，何らかの理由で，シャットダウン
している，またはスレッド数が最大かつタスク実行の図5検出した Dependent Test の例 †5

キューが飽和状態である場合に発生する．開発者は失敗の理由を特定する必要があるが，実行環境など，

テスト getCurrentUsername()（14 行目）を示す．

テスト以外に原因がある可能性もあり，多大な労力を通 常 は getCurrentUsernameForNoAuth() が 先費やす必要があると考えられる．しかし，テスト結果に 実 行 さ れ る が ，実 行 順 を 入 れ 替 え るが不安定なだけと考え，失敗原因を特定しない場合，と ，getCurrentUsername() に よ り static 変 数

プロダクトのバグを見逃す可能性がある．そのため，

username の値が"admin"に設定されるため，28 行

検出ツールにより，早期に発見することが望ましい．

目でアサーションエラーが発生する．JUnit4 はデ

図 5 に jwt-spring-security-demo プロジェクトに含フォルトでは実行順序をテストメソッド名のハッシュ値に基づいて決定する †6 ．そのため，これらのテス

まれる Dependent Test である getCurrentUsername

トは偶然どちらも成功する順序で実行されているだけ

ForNoAuth() （24 行目）と，このテストが依存するであり，メソッド名の変更やテストの追加などで実行

4. 4. 3 Dependent Test

†3 https://github.com/akarnokd/RxJavaInterop/
blob/ce111/src/test/java/hu/akarnokd/rxjava3/
interop/RxJavaInteropTest.java#L432†4 https://github.com/auth0/java-jwt/blob/90bce/
lib/src/test/java/com/auth0/jwt/ConcurrentVer
ifyTest.java#L84†5 https://github.com/szerhusenBC/jwt-springsecurity-demo/blob/dcf71/src/test/java/org/
zerhusen/security/SecurityUtilsTest.java#L25†6 https://github.com/junit-team/junit4/wiki/
Test-execution-order58

コンピュータソフトウェア

順序が変わると，getCurrentUsernameForNoAuth()

ツールですべての動的スメルを検出することができのテストは失敗する．しかし，開発者はすぐには実行

るため，開発者の生産性向上につながる．

順序の変更がテストの失敗とは考えないため，原因のテストスメル検出手法の IDE への統合も行われて

特定に時間を費やすこととなる．JTDog を利用すれいる．Bleser らは，6 種類のテストスメルを検出でば，このような潜在的問題を検出することができる．

きる IntelliJ プラグイン SoCRATES を開発した [6]．

Lambiase らは，3 種類のテストスメルを検出し，自動5 関連研究

リファクタリングを行うことができる IntelliJ プラグ

現在までに数多くのテストスメル検出ツールが提案

イン DARTS を構築した [17]．Eclipse プラグインもされている．Breugelmans と Rompaey は，検出ツー

作成されており，Baker らは TReX を [1]，Santana らルとして TestQ を開発した [7]．このツールは，開発

は RAIDE [27] を開発した．これらのプラグインにつ者がテストスイートを視覚的に探索するためのイン

いても，自動リファクタリングがサポートされている．

ターフェースを提供する．Greiler らは，テストフィ

また，Koochakzadeh と Garousi が開発した TeRe-

クスチャに関連する新しいテストスメルを導入し，検Detect [15] と TeCReVis [16] は，CodeCover [8] と出ツールである TestHound を構築した [12]．Greiler

いう Eclipse プラグインに統合されている．テストス

らはその後の研究で，TestHound を Git や SVN のリ

メル検出技術を IDE に統合することで，ユーザのテ

ポジトリを解析できるように拡張し，TestEvoHoundストスメル検出のコストを削減することができる．同を作成した [13]．Palomba らは，テキスト分析によっ

様に，JTDog は，動的スメル検出手法を Gradle に統て 3 種類のテストスメルを検出するツール TASTE

合することで，ユーザが容易にテストスメルを検出でを開発した [23]．Bavota らは 9 種類のテストスメ

きるよう支援する．

ルを検出するテストスメル検出ツールを作成し [4]，Peruma らは，19 種類のテストスメルを検出可能な

6 おわりに

ツール tsDetect を提案した [25]．これらのツールは

本論文では，動的なテストスメルを検出する Gra-

いずれも静的スメルのみ検出することができ，JTDog

dle プラグイン JTDog を紹介した．適用実験ではと補完関係にある．双方のツールを組み合わせるこ

GitHub 上の 205 プロジェクトに対して JTDog を使とで，より良いテストの作成を支援できる．

用し，本プラグインの可搬性および検出機能の確認

我々が動的スメルに分類した 3 つのテストスメルを行った．その結果，JTDog は 66 プロジェクトかそれぞれについて，その検出を目的としたツールもら 1,117 個の動的スメルを検出することができた．今

提案されている．Delplanque らは，新たなテストス

後の課題としては，動的スメル検出手法の改善や，メルとして Rotten Green Test を提案し，検出ツー

JTDog に静的スメルの検出機能を追加して広範なテルとして DrTest を考案した [9]．DrTest は Pharo

ストスメル検出ツールとすること，TestNG などの他という言語で記述されたプログラムを対象とするたの Java テストフレームワークのテストを解析を可能

め，Martinez らは，Java プログラムを対象としたにすることが挙げられる．

Rotten Green Test 検出ツールである RTj を開発した [19]．Dependent Test を検出するために，Zhang

謝辞 本研究の一部は，JSPS 科研費 JP21H04877
および JP21K11829 による助成を受けた．

らは DTDetector を [28]，Gambi らは PRADET を構築した [11]．Bell らは，Flaky Test の新たな検出

参 考 文 献手法を提案し，DeFlaker を実装した [5]．これらはす[ 1 ] Baker, P., Evans, D., Grabowski, J., Neukirchen,H., and Zeiss, B.: TRex - The Refactoring and Metrics Tool for TTCN-3 Test Speciﬁcations, Testing:Academic & Industrial Conference - Practice And
Research Techniques, 2006, pp. 90–94.

べてスタンドアロンツールである．我々は各動的スメ
ルの検出機能を統合して Gradle プラグインとした．
ビルドツールへの統合により高可搬性を有し，1 つのVol. 39 No. 4 Nov. 2022
[ 2 ] Bavota, G., Qusef, A., Oliveto, R., Lucia, A.,
and Binkley, D.: An empirical analysis of the distribution of unit test smells and their impact on
software maintenance, International Conference on
Software Maintenance, 2012, pp. 56–65.
[ 3 ] Bavota, G., Qusef, A., Oliveto, R., Lucia, A.,
and Binkley, D.: Are Test Smells Really Harmful?
An Empirical Study, Empirical Software Engineering, Vol. 20, No. 4(2015), pp. 1052–1094.
[ 4 ] Bavota, G., Qusef, A., Oliveto, R., Lucia, A. D.,
and Binkley, D.: An empirical analysis of the distribution of unit test smells and their impact on
software maintenance, International Conference on
Software Maintenance, 2012, pp. 56–65.
[ 5 ] Bell, J., Legunsen, O., Hilton, M., Eloussi, L.,
Yung, T., and Marinov, D.: DeFlaker: Automatically Detecting Flaky Tests, International Conference on Software Engineering, 2018, pp. 433–444.
[ 6 ] Bleser, J. D., Nucci, D. D., and Roover, C. D.:
SoCRATES: Scala Radar for Test Smells, Symposium on Scala, 2019, pp. 22–26.
[ 7 ] Breugelmans, M. and Rompaey, B. V.: TestQ:
Exploring Structural and Maintenance Characteristics of Unit Test Suites, International Workshop on
Advanced Software Development Tools and Techniques, 2008.
[ 8 ] CodeCover: http://codecover.org/index.html.
[ 9 ] Delplanque, J., Ducasse, S., Polito, G., Black,
A. P., and Etien, A.: Rotten Green Tests, International Conference on Software Engineering, 2019,
pp. 500–511.
[10] Deursen, A., Moonen, L., Bergh, A., and Kok,
G.: Refactoring Test Code, International Conference on Extreme Programming and Flexible Processes in Software Engineering, 2001, pp. 92–95.
[11] Gambi, A., Bell, J., and Zeller, A.: Practical
Test Dependency Detection, International Conference on Software Testing, Veriﬁcation and Validation, 2018, pp. 1–11.
[12] Greiler, M., van Deursen, A., and Storey, M.:
Automated Detection of Test Fixture Strategies andSmells, International Conference on Software Testing, Veriﬁcation and Validation, 2013, pp. 322–331.
[13] Greiler, M., Zaidman, A., van Deursen, A.,
and Storey, M.: Strategies for avoiding text ﬁxture smells during software evolution, Working
Conference on Mining Software Repositories, 2013,
pp. 387–396.
[14] Herzig, K. and Nagappan, N.: Empirically Detecting False Test Alarms Using Association Rules,
International Conference on Software Engineering,
2015, pp. 39–48.
[15] Koochakzadeh, N. and Garousi, V.:A
Tester-Assisted Methodology for Test Redundancy
Detection, Advances in Software Engineering,Vol. 2010(2010).
[16] Koochakzadeh, N. and Garousi, V.: TeCReVis:
A Tool for Test Coverage and Test Redundancy Vi-

59

sualization, Testing – Practice and Research Techniques, 2010, pp. 129–136.
[17] Lambiase, S., Cupito, A., Pecorelli, F., Lucia,
A. D., and Palomba, F.: Just-In-Time Test Smell
Detection and Refactoring: The DARTS Project,International Conference on Program Comprehension, 2020, pp. 441–445.
[18] Luo, Q., Hariri, F., Eloussi, L., and Marinov, D.:
An Empirical Analysis of Flaky Tests, International
Symposium on Foundations of Software Engineering, 2014, pp. 643–653.
[19] Martinez, M., Etien, A., Ducasse, S., andFuhrman, C.: RTj: A Java Framework for Detecting
and Refactoring Rotten Green Test Cases, International Conference on Software Engineering, 2020,
pp. 69–72.
[20] Meszaros, G.: xUnit test patterns: Refactoring
test code, Pearson Education, 2007.
[21] Micco, J.: Flaky Tests at Google and How
We Mitigate Them, https://testing.googleblog.
com/2016/05/flaky-tests-at-google-and-how-we.
html, 2016.
[22] Micco, J.: The State of Continuous Integration Testing Google, https://research.google.
com/pubs/pub45880.html, 2017.
[23] Palomba, F., Zaidman, A., and Lucia, A. D.:
Automatic Test Smell Detection Using Information Retrieval Techniques, International Conference on Software Maintenance and Evolution, 2018,
pp. 311–322.
[24] Peruma, A.: What the Smell? An Empirical Investigation on the Distribution and Severity of Test
Smells in Open Source Android Applications, Master’s thesis, Rochester Institute of Technology, 2018.
[25] Peruma, A., Almalki, K., Newman, C., Mkaouer,
M., Ouni, A., and Palomba, F.: tsDetect: An Open
Source Test Smells Detection Tool, Joint Meetingon European Software Engineering Conference andSymposium on the Foundations of Software Engineering, Association for Computing Machinery,
2020, pp. 1650–1654.
[26] Rompaey, B. V., Bois, B. D., and Demeyer, S.:
Characterizing the Relative Signiﬁcance of a Test
Smell, International Conference on Software Maintenance, 2006, pp. 391–400.
[27] Santana, R., Martins, L., Rocha, L., Virgı́nio,T., Cruz, A., Costa, H., and Machado, I.: RAIDE:A Tool for Assertion Roulette and Duplicate Assert
Identiﬁcation and Refactoring, Proceedings of the34th Brazilian Symposium on Software Engineering, 2020, pp. 374–379.
[28] Zhang, S., Jalali, D., Wuttke, J., Muşlu, K.,
Lam, W., Ernst, M., and Notkin, D.: Empirically
Revisiting the Test Independence Assumption, International Symposium on Software Testing andAnalysis, 2014, pp. 385–396.

コンピュータソフトウェア

60
谷口真幸

2021 年大阪大学基礎工学部情報科学科卒業．同年より同大学大学院情報科学研究科コンピュータサイエン
ス専攻博士前期課程在学中．ソフト
ウェアテストの分析に関する研究に従事．

科助教．博士（工学）．エンピリカルソフトウェア工学の研究に従事．
楠本真二

1988 年 大 阪 大 学 基 礎 工 学 部 卒 業 ．
1991 年同大学大学院博士課程中退．
同年同大学基礎工学部助手．1996 年

柗本真佑2010 年奈良先端科学技術大学院大学
博士後期課程修了．同年神戸大学大学院システム情報学研究科特命助教．

2016 年大阪大学大学院情報科学研究

同講師．1999 年同助教授．2002 年
同大学大学院情報科学研究科助教授．2005 年同教授．
博士（工学）．ソフトウェアの生産性や品質の定量的評価に関する研究に従事．電子情報通信学会，IEEE，

IFPUG 各会員．