**2024/5/13週**

①テスト自動生成ツールによって生成されたテストは本当にバグ発見に役立つのか？
②テストコードの分析
③コード（メソッド）の進化とテストの関係はどうなっているのか？

②やる

> よいテストコードとしては，構造が簡単（分岐がない）やアサーションの数が少ない等があるが，実際のテストコードはどうなっているだろうか．

まずはテストのソースコードを取ってきて分岐が含まれていないか調べる

GitHubからJavaプロジェクトをとってくる
大規模から小規模まであるが、大規模なもの（いいとされているもの）を対象にする
スター（いいね）がたくさんついているJavaプロジェクトをとってくる

プロジェクトの取り方
①clone(1つ1つのプロジェクトを操作)
②API(複数プロジェクトをまとめて操作)

とってきたあとはテストが付属しているか確認(目視)

src→main→jp→ac
→test

srcディレクトリの直下を確認

テストに分岐があるか確認する方法
目視orプログラム解析　ASTを作ってvisitする
Java関係のツールを使う

**来週までの課題**
*GitHubからJavaプロジェクトをとってくる*
大規模から小規模まであるが、大規模なもの（いいとされているもの）を対象にする
スター（いいね）がたくさんついているJavaプロジェクトをとってくる
ツールのレクチャーから1週間程度でプログラムを完成できるはず？

質問はSlackのgroup-a or HackMDに書き込む

**2024/5/20週**
環境構築上の問題を解決
→Javaのコンパイラ/実行環境のバージョンが一致しないことで発生した問題だった
設定→JavaSでJREバージョンとコンパイラバージョンを一致させれば解決

Javaのテストプログラムの条件分岐をカウントするプログラム作成
* 条件分岐の定義は何？最初はifだけカウントするプログラムを作成→whileとか追加
* Visitorメソッドでカウントした変数はどうmainに引き継げばいい？
* ファイルのたどり方で効率よくPathを辿れる方法はないか？正規表現とか？

**実装方法**
* if/switch/while/forの個数をカウント
* 変数の引き継ぎはgetterを利用
* fileFilterとと再起探索を利用し、指定ディレクトリ以下のjavaファイルを探索

オープンソースのテストコードを取ってきて、分岐の数などを解析する
解析して考察した結果を報告する、分析方法は自分で考える

Google Scholarのテストコードの論文（特に分岐の有無について言及した論文）を読んでみる
被引用件数の多い(10件以上)をダウンロード
分岐：branchなど
論文は英語と日本語両方確認（翻訳版と原語版両方読む）

Javaの文法・言語仕様確認
分岐の取りこぼしがないか確認

自分で何をすべきか考えてから相談、指示待ちではいけない
努力して自分の能力を上げるのが一番

気になる書籍
Java in a Nutshell

**2024/6/21週**
合計何このメソッドを対象に調べたか書く
それぞれのテストメソッドでどれくらい分岐が起きているか調べる
サイクロマチック複雑度
サイクロマチック複雑度＝分岐の数
自分で調べてみる
分岐が含まれる・含まれない

テストの中にコードがあまり分岐を含まないのは暗黙知
分岐がないはずなのにあることによって生じる不都合を調べる

カバレッジ：対象のコードがどれくらいテストによってカバーされているか

複雑な分岐が含まれるプログラムとシンプルなプログラムでカバレッジを比べてみる

各テストメソッドでサイクロマチック複雑度（分岐の数）
**制御フローが何個分岐する可能性があるところが存在するか**
それの手段としてソースコードの分岐の出現数をカウントする
分岐が何個出現したかをヒストグラムみたいな図にまとめて木曜持ってくる

カバレッジ計測ツールの使い方を濱本くんか清水さんに教えてもらう

2024/6/26
調べる対象は×クラスファイル(1個のjavaファイル)〇メソッド？
クラスファイルバージョンとメソッドバージョン2種類の探索プログラム作る？
自分の技術力ではクラスファイルを探索するのが限界。肥後先生に確認する

**クラスファイル単位(notメソッド単位)の計測結果**
調査したクラス数は**16563個**
サイクロマティック複雑度とプログラム全体に占める割合
* 1(分岐構造なし)：76.83%
* 2-10:17.43%
* 11-29:4.46%
* 30-49:0.77%
* 50-74:0.32%
* 75-:0.19%

**サイクロマティック複雑度の定義**
**分岐構造(if, else-if, switch, case, while, do-while, for)の個数の合計+1**

**ヒストグラムの範囲設定の参考**
https://jp.mathworks.com/discovery/cyclomatic-complexity.html

**分かったこと**
* 多くのテストコードは「いいテストコードは分岐構造が少ない」の原則のもと作成されている
* サイクロマティック複雑度が極端に高いのは
* 分岐構造の処理そのものがテスト内容に含まれている
* データの代入などテストとは関係ない場所で分岐が多用されている
* の2つに分けられそう

**してみたいこと**
* 分岐があることにより生じる不都合の調査
↑
* カバレッジ計測・計測結果の比較
* サイクロマチック複雑度の低い/高いプログラムをピックアップしてプログラムのカバレッジを計測・比較
* サイクロマチック複雑度が高いプログラムのリファクタリング前後で比較してみる？

クラスファイルという言い方はよくない
クラスファイルには.classというコンパイル後のファイルという意味があるため
ソースコードを指したいのなら.javaファイルをいうべし

サイクロマチック複雑度は「1メソッド内の」分岐構造の数
メソッド単位で計測するようにプログラム組み直し！

カバレッジはテストコードで「テストされるコード」を基準に測定
してみたいことの方向性はいいんじゃない？とのこと。院試後に取り組む

**2024/8/6**
今後の研究方針について、自分なりにどう考えているのかまとめて資料をつくってくること
**研究テーマ**　**「いいテストコードとは何か」**

今までの成果

* テストコードに関連した論文の調査
* GitHubからスター数の多いJavaプロジェクトを収集、大規模プロジェクトを中心に解析(サイクロマチック複雑度の計測)
* (JDTCoreによる構文解析をもとに、メソッド単位で制御構造の個数をカウント)←メソッド単位でカウントするよう修正中
* ※制御構造...if, for, while, do-while, switch, case

現時点の考え

* 分岐(制御構造)があることによりどのような不都合が生じるか知りたい
* 「いいテストコードは分岐が少ない」の原則に反することでどのような問題が発生するのか
* カバレッジの計測
* テストコードで、「テストされるコード」を基準に計測
* サイクロマチック複雑度の低い/高いプログラムをピックアップし、カバレッジを計測した結果を比較
* サイクロマチック複雑度が極端に高いものは、大まかに分けて
* 分岐構造の処理そのものがテスト内容に含まれている
* データの代入などテストとは関係ない場所で分岐が大量に使用されている
* の2つの場合に分けられる。それぞれのケースに該当するプログラムをピックアップ・カバレッジを計測した結果を比較すると何かわかるのではないか

いいテストコードの「いい」はどんな意味？
↑調べる、テストコード関係の論文を読む

テストコードの修正回数を調べてみてもいいのでは
↑よくないテストコードは修正された回数が多い？
finergit(メソッド単位で修正回数がわかる)調べてみる
Y. Higo, S. Hayashi, and S. Kusumoto, "On Tracking Java Methods with Git Mechanisms," Journal of Systems and Software, 165, July 2020.

時間がかかるのは実験の後半、考察に時間がかかる？
解析するプログラムを完成するのはウェイトを置きたくない

査読付き論文も対外発表も多大な負荷がかかる、自分はそれに耐えられるか。岸本さんや音田さん、吉田さん、井上さんにも対外発表の話を聞いてみる

2024/09/24
まだ研究の途中段階 だと思いますので，提案手法の詳細や実験結果は発表する必要ありません．
「研究の目的(背景)」，「研究目的を達成する手段(提案手法)」，「自分の研究と既存研究との差」をしっかりとアピールしてください．

**テストコードの分析**

*よいテストコードとしては，構造が簡単（分岐がない）やアサーションの数が少ない等があるが，実際のテストコードはどうなっているだろうか．
また，よい構造をしているテストの方が対象メソッドに帯するコードカバレッジは高いだろうか？
悪い構造をしているテストがあったときその原因は何だろうか？悪い構造を持ったテストになっている原因は悪い構造を持ったプロダクトコードになっていないだろうか**

2024/9/29

いいテストコードの(通説的な)定義
メソッド単位に含まれる分岐構造の数が少ない
※ここではif, for while, do-while, switch, case構文の6種類
アサーションの数が少ない

すること
いいテストコードのコードカバレッジをEvoSuiteで計測
計測結果を数字を出しながら比較
悪い構造になっている原因を考察

2024/11/11

**スピアマンの相関係数とp値の計算結果**

**調査対象**
プロダクトコードと、それに1対1に対応しているテストコード(例:A.javaとATest.java)441組


**結論**
あるプロダクトコードのC0(命令網羅率)、およびC1(分岐網羅率)とそれに対応するテストコードの1テストメソッド当たりのサイクロマティック複雑度には、**弱い相関が見られた。** ただしp値がいずれも0.05を大きく上回っており、統計としての信ぴょう性は低い。

p値が低い主な原因:サンプル数が441と少ない
解決策:サンプル数を増やす(計測対象のプロダクトコード＆テストコードの数を増やす)

**散布図と近似直線**

C0とテストメソッド1つ当たりのサイクロマティック複雑度

C1とテストメソッド1つ当たりのサイクロマティック複雑度

C0, C1とサイクロマティック複雑度の関係は、弱い関係ではあるものの **「よいテストコードは、分岐の数が少ない(カバレッジの高いプロダクトコードに付随するテストコードのサイクロマティック複雑度は低い)」** という通説に従う。

C0とC1

C0とC1は強い比例関係にある。

**悩んでいること**
* スピアマンの相関係数や近似曲線を導出する際、外れ値(傾向から大きく異なる値)を除外すべきか。
* p値を小さくする方法で、サンプル数を増やす、統計手法を変更する以外の方法はあるか。

2024/12/27