こんにちはラボルの中垣です。
IntelliJ っていいですよね。今回は IntelliJ のコードカバレッジを手動テストでも使えることがわかったので紹介します。
- IntelliJ のコードカバレッジってどういうもの？
- なんで手動テストでもコードカバレッジがほしいの？
- どうやって手動テストのカバレッジを取るの？
- 手動テストでコードカバレッジをとる良いところと悪いところ
- 最後に
IntelliJ のコードカバレッジってどういうもの？
IntelliJ の code coverage 機能はどのコードがテストできているのかを表示してくれるものです。プロジェクト全体がどの程度カバーされているのかやコードの横にどこがカバーされているか表示してくれるのでとても便利です。
カバーされているコードが緑、カバーされていないコードが赤
カバレッジは普通は自動テストで使いますが、手動テストするときでもカバレッジが取れるんです。
なんで手動テストでもコードカバレッジがほしいの？
カバレッジは大抵自動テストでやるものですが、ラボルで起こったバグがきっかけで手動テストでもカバレッジがとれると役立つかもという考えになりました。
ちなみにラボルでは複雑で大事なロジックを持った部分を単体テスト（自動テスト）で守り、結合部分のコード（HTTP Request のハンドリングや Database 接続など）の大半は手動でテストをしています。結合部分は自動で実行できるテストコードを書いても大変なので割に合わないという判断でこうなってます。
バグの内容はある機能がある条件でエラーになって使えなくなるものです。原因はシンプルに実行されたら必ずエラーが出るコードがあったからでした。今回エラーが起きた部分は結合部分なので手動テストで問題の分岐のテストが抜けていました。テストをするときにある分岐のテストが抜けていたってことは全然これからもありそうなので同じような悲しみを生まない方法が欲しくなりました。
人の確認ですべての分岐がテストされているかチェックするのは難しそうですよね。ムリムリ。でもコードカバレッジがあったらテスト時にすべての分岐が実行されたかがわかるので防げそうと思いました。これなら開発者はテスト時に実行していないコードがあることに気づけて、テストをレビューする人もカバレッジは気にせずレビューできます。そこで使えるツールが無いか探してみたところ、見つけたのが IntelliJ のコードカバレッジの機能です。手動テストでも使えることで僕の頭は blown away. By the way. Anyway. Which way? That way.
どうやって手動テストのカバレッジを取るの？
このセクションではカバレッジのとり方や注意点を紹介します。
手動テストでカバレッジをとる手順
このような手順で手動実行のコードカバレッジが取れます。
- カバレッジありでアプリケーション実行
盾アイコンでカバレッジありで実行できる - 手動テストを実施
- アプリケーションを終了させる
アプリケーションを止めた段階でコード上のカバレッジとカバレッジのレポートが表示されます。
手動テストのカバレッジの注意点
手動テストのカバレッジを取る場合、カバレッジをとったあともう一回カバレッジを取ろうとすると以前のカバレッジデータがリセットされてしまいます。下記のシナリオの場合にグサッと IntelliJ に背中を刺されます。
- カバレッジありで手動テスト開始！
- 終わったのでアプリケーションを終了させてカバレッジをチェック
- もう一回カバレッジありで抜けてたところを手動テストする
- アプリケーション終了させてカバレッジチェック
- リセットされて最後に抜けてるところしかカバーできてないことになってる！
これは抜けている箇所が少なかったらそこだけカバーできていることが確認できれば OK かもしれないですが、やっぱり最終的に 100%カバレッジを確認したいです。ちょい Perfectionist の僕には辛いですね。Perfectionist は色々面倒なのでこの機会にやめるのもいい考えですね。でも実は Perfectionist でもハッピーな方法があるんです！
めっちゃ niche な状況のためにコードカバレッジデータを操作する！
先程の悲しいシナリオでも IntelliJ のコードカバレッジデータをうまく操作すればカバレッジ 100%を目指せます。下記の操作でできます。
- カバレッジありで手動テスト開始！
- 終わったのでアプリケーションを終了させてカバレッジをチェック
- アプリケーションの RunConfiguration をコピーしてもう一個作る
- 新しい RunConfiguration を使って もう一回カバレッジありで抜けてたところを手動テストする
- アプリケーション終了させてカバレッジチェック
- リセットされて最後に抜けてるところしかカバーできてないことになってる！
カバレッジのデータはCoverage Suiteに保存されていて、Coverage SuiteはRun Configurationに紐づきます。なので別のRun Configurationを作ることに寄ってカバレッジデータを新しい方に保存して、以前のカバレッジデータを残しておくことが可能になります。ついでに単語の説明も軽くしておきます。
Run Configuration: 実行するものの設定です。- アプリケーションやテストがこれに入ります。
Coverage SuiteはRun Configurationに対してのカバレッジデータを持ってるものです。Coverage SuiteとRun Configurationは 1:1 の関係になってます。
手動テストでコードカバレッジをとる良いところと悪いところ
良いところ
- テストし忘れたコードをなくせる
- 手動テストでもカバレッジを取る前提にしたらテストのレビュー時にカバレッジを気にしないで良くなる
悪いところ
- workaround をしないとカバレッジ 100%にできないため、ルール化が難しい
- プルリク単位でのカバレッジが見れない 既存クラスを修正した場合は修正箇所だけのカバレッジがほしいですが、それができないため既存クラスの修正の場合は使いづらい
いけてないところがありますね、おしい。ラボルでは手動テストでのカバレッジはルール化してないので、個々の判断で必要だったらやるようにしています。個人的に手動テストでカバレッジを取るのは新機能を追加の最終確認が一番 Umami があるのでそういうシチュエーションに使う予定です。やっぱり IntelliJ いいですね。
最後に
ラボルでは、エンジニアを積極採用中です。1、2年目のエンジニアから経験豊富なテックリードやエンジニリングマネージャーまで、興味がある方はぜひご応募ください!!
