ソフトウェア開発で大きなウェイトを占める「テスト」。
品質を高めるための大事な作業ですが、テスト工程を完了しリリースしたにも関わらず、後でバグが発見されるということも多くあります。
アジャイル開発を採用するプロジェクトが増える中で、アジャイルソフトウエア開発宣言にある『包括的なドキュメントよりも”動くソフトウェア”を』の通り”動くソフトウェア”を常に作るために、テスト駆動開発をしようと考えるエンジニアは多いでしょう。
その「テスト駆動開発」。
テストコードを書く＝その分時間がかかる、というイメージを持ってしまいますが、果たして品質は上がるのか、見ていきたいと思います。
品質を高めるための大事な作業ですが、テスト工程を完了しリリースしたにも関わらず、後でバグが発見されるということも多くあります。
アジャイル開発を採用するプロジェクトが増える中で、アジャイルソフトウエア開発宣言にある『包括的なドキュメントよりも”動くソフトウェア”を』の通り”動くソフトウェア”を常に作るために、テスト駆動開発をしようと考えるエンジニアは多いでしょう。
その「テスト駆動開発」。
テストコードを書く＝その分時間がかかる、というイメージを持ってしまいますが、果たして品質は上がるのか、見ていきたいと思います。
テスト駆動開発とは？
名前の通り、テストファーストでプログラムを作っていく手法です。
「テスト駆動開発とは」を、ここで下手に解説するよりも、テストと言えば「和田卓人」さん。
日本における第一人者でご存知の方も多いでしょう。
de:code2017で登壇された際の解説がとてもわかりやすいので、「とは？」を知りたい方は是非見てください。
テスト駆動開発とは何か、に始まり、FIZZ/BUZZ問題を例に、ライブコーディングでRED→GREEN→REFACTORINGのサイクルをどう進めるのか、流れを見ることができます。
プログラミングする際、要件をTODOリストに落とすやり方も、テスト駆動開発についても「なるほど！」と思えます。
【50分でわかるテスト駆動開発 和田卓人】
https://channel9.msdn.com/Events/de-code/2017/DO03
「テスト駆動開発とは」を、ここで下手に解説するよりも、テストと言えば「和田卓人」さん。
日本における第一人者でご存知の方も多いでしょう。
de:code2017で登壇された際の解説がとてもわかりやすいので、「とは？」を知りたい方は是非見てください。
テスト駆動開発とは何か、に始まり、FIZZ/BUZZ問題を例に、ライブコーディングでRED→GREEN→REFACTORINGのサイクルをどう進めるのか、流れを見ることができます。
プログラミングする際、要件をTODOリストに落とすやり方も、テスト駆動開発についても「なるほど！」と思えます。
【50分でわかるテスト駆動開発 和田卓人】
https://channel9.msdn.com/Events/de-code/2017/DO03
テスト駆動開発のメリット、デメリット
さて、前項の和田卓人さんの動画を見られた方は、テストコードの重要性についても理解できたと思います。
筆者から見るとメリットに比べればデメリットは些細なものに思えるのですが、一旦デメリットについて考えてみます。
意識の高いエンジニア、スキルの高いエンジニアは、言われずともテストコードを書いている場合がありますが、チームがテスト駆動開発をしていない場合、プロマネからチームメンバーに「テストコードを書いて」とお願いしても、そんな時間はない、煩わしい、面倒、と否定的な反応が帰ってくる場合も多く、なかなか現場のエンジニアは動いてくれない場合があります。
進めるには、ある程度安心して手を動かせるスケジュール設定や環境が必要です。
テストコードを書けば良い、というものではないので「テスト駆動開発とは」を理解した上で進める必要があります。
エンジニアなら、前項の和田卓人さんの動画で十分理解できると思うので、あとは腕を磨く場を作ることです。
ペアプロや、モブプログラミングすると良いでしょう。
経験のないチームの場合、やはりテストコードを書きながら開発するのは時間がかかります。
費用やスケジュールの見積もり時点で、この「助走分」を見込んでおく必要があります。
慣れてくればスピードは上がるのですが、初期段階はスケジュールを緩めにするなどで、配慮しておくと良いですね。
仕様変更に伴ってテストコードを追加する作業はもちろん、和田卓人さんの動画にもあるように、不要なテストコードを削除するというのが難しいという問題があります。
更に、テストコードが増えるのは非常に良いことですが、時間がかかるようになってくると見直しや環境の変更が必要になることがあります。
一方メリットは、言わずもがな。
逆に言うと後で発見するバグ程、修正コストがかかります。
書いた本人もコードの詳細を忘れていますし、本人が修正するとも限りません。
後工程で発見したバグは、テストする箇所も多岐に渡ってしまいます。
テスト駆動開発をしていても、勿論総合テストやE2Eのテストは必要ですが、単体で強固なものができていれば後工程で爆発！ということが起きにくいと言えます。
また、テスト時点で仕様漏れを発見することが多くあるので、テストに関わらず、要件の抜け漏れ、検討不足を防ぐこともあります。
テストはエビデンスです。システムの仕様変更や影響範囲の大きい修正が発生した場合、今まで書いたテストをクリアしていれば、少なくとも既存部分は安全と保証されます。
運用中のシステムならなおさらで、リリース後に緊急の電話がかかってくるのでは？とドキドキしながら帰路につくということも少なくなるでしょう。
筆者から見るとメリットに比べればデメリットは些細なものに思えるのですが、一旦デメリットについて考えてみます。
・現場エンジニアが動かない
意識の高いエンジニア、スキルの高いエンジニアは、言われずともテストコードを書いている場合がありますが、チームがテスト駆動開発をしていない場合、プロマネからチームメンバーに「テストコードを書いて」とお願いしても、そんな時間はない、煩わしい、面倒、と否定的な反応が帰ってくる場合も多く、なかなか現場のエンジニアは動いてくれない場合があります。
進めるには、ある程度安心して手を動かせるスケジュール設定や環境が必要です。
・教育が必要
テストコードを書けば良い、というものではないので「テスト駆動開発とは」を理解した上で進める必要があります。
エンジニアなら、前項の和田卓人さんの動画で十分理解できると思うので、あとは腕を磨く場を作ることです。
ペアプロや、モブプログラミングすると良いでしょう。
・慣れるまでの助走期間が必要
経験のないチームの場合、やはりテストコードを書きながら開発するのは時間がかかります。
費用やスケジュールの見積もり時点で、この「助走分」を見込んでおく必要があります。
慣れてくればスピードは上がるのですが、初期段階はスケジュールを緩めにするなどで、配慮しておくと良いですね。
・テストコード自体のメンテナンス
仕様変更に伴ってテストコードを追加する作業はもちろん、和田卓人さんの動画にもあるように、不要なテストコードを削除するというのが難しいという問題があります。
更に、テストコードが増えるのは非常に良いことですが、時間がかかるようになってくると見直しや環境の変更が必要になることがあります。
一方メリットは、言わずもがな。
・バグは早く発見するほど修正コストが低くすむ
逆に言うと後で発見するバグ程、修正コストがかかります。
書いた本人もコードの詳細を忘れていますし、本人が修正するとも限りません。
後工程で発見したバグは、テストする箇所も多岐に渡ってしまいます。
・後工程が軽くすむ
テスト駆動開発をしていても、勿論総合テストやE2Eのテストは必要ですが、単体で強固なものができていれば後工程で爆発！ということが起きにくいと言えます。
また、テスト時点で仕様漏れを発見することが多くあるので、テストに関わらず、要件の抜け漏れ、検討不足を防ぐこともあります。
・安心して夜眠れる
テストはエビデンスです。システムの仕様変更や影響範囲の大きい修正が発生した場合、今まで書いたテストをクリアしていれば、少なくとも既存部分は安全と保証されます。
運用中のシステムならなおさらで、リリース後に緊急の電話がかかってくるのでは？とドキドキしながら帰路につくということも少なくなるでしょう。
Googleのテストカバレッジはなんと78%！
ここからは、Developers Summit 2021 に登壇された
ロジギアジャパン 高橋 寿一さんの講演「ソフトウェア品質を高める開発者テスト」が非常に興味深かったので、講演内容を基にテストについて考えていきます。
タイトルの通り、なんと、Googleのテストカバレッジ(網羅率)は78%ということです。
さすがGoogle、高いですね。
講演が撮影OKだったので、スライドをお借りして紹介していきます。
高橋さんによると、彼らはE2Eのテストは殆どしないらしく、聞くと「意味ないでしょ」という事らしいです。
確かにここまでテストコードが書けていると、プログラマーのスキルも高いでしょうし、強固なシステムになってるのでしょうね。
ロジギアジャパン 高橋 寿一さんの講演「ソフトウェア品質を高める開発者テスト」が非常に興味深かったので、講演内容を基にテストについて考えていきます。
タイトルの通り、なんと、Googleのテストカバレッジ(網羅率)は78%ということです。
さすがGoogle、高いですね。
講演が撮影OKだったので、スライドをお借りして紹介していきます。
高橋さんによると、彼らはE2Eのテストは殆どしないらしく、聞くと「意味ないでしょ」という事らしいです。
確かにここまでテストコードが書けていると、プログラマーのスキルも高いでしょうし、強固なシステムになってるのでしょうね。
Googleの単体テスト基準
やはり「書けばいい」ではないので、基準があるようです。
これはピックアップされたもののようで、原文を探してみたところ、Googleのテストブログにありました。
Code Coverage Best Practices
(コードカバレッジのベストプラクティス)
https://testing.googleblog.com/2020/08/code-coverage-best-practices.html
なにやら参考になることがたくさん書かれています。
ちなみに前項でGoogleはE2Eのテストを殆どしない、と紹介しましたが、それを匂わせる内容の記事もありました。
Just Say No to More End-to-End Tests
(エンドツーエンドのテストをこれ以上やらないでください)
https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
ただこの記事は沢山コメントがついていて、賛否ありそうです。
これはピックアップされたもののようで、原文を探してみたところ、Googleのテストブログにありました。
Code Coverage Best Practices
(コードカバレッジのベストプラクティス)
https://testing.googleblog.com/2020/08/code-coverage-best-practices.html
なにやら参考になることがたくさん書かれています。
ちなみに前項でGoogleはE2Eのテストを殆どしない、と紹介しましたが、それを匂わせる内容の記事もありました。
Just Say No to More End-to-End Tests
(エンドツーエンドのテストをこれ以上やらないでください)
https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
ただこの記事は沢山コメントがついていて、賛否ありそうです。
2:8の法則ご存知ですか？全体の2割の箇所にバグの8割が潜んでいる
ここからは、Googleの事例ではなく高橋さんの経験や知識に基づくものだと思います。
レガシーなシステムで全てのテストコードを今さら書くのが難しい場合、2:8の法則に則ってテストコードを書くと良いそうです。
これは論文も出ている確かな数字らしく、筆者ももっと早く知りたかった内容です。
では、バグが潜んでいる2割はどこなのか。
確かに、言われると納得です。
また、どうテストするのかというのも大事なことで
CircleCIやJenkinsを使って自動化する、自動化したテストが丸一日かかる等がないようにする。
これはテストが重くなる問題にハマらないようにするということですね。
また、静的解析も役に立ちます。
テストが重くなる原因のひとつに、全部を自動化しようとすること。UIをなぞろうとすること。
攻めたい内容によって適切なテスト手法を取るということですね。
他にも、ためになる話を沢山されていたのですが詳しく知りたい方は、講演者の本を読んでみてはと思います。
ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方
https://www.amazon.co.jp/dp/B08TBD3LSS/ref=cm_sw_em_r_mt_dp_F2VEQSF822CSFB6MX1T8
レガシーなシステムで全てのテストコードを今さら書くのが難しい場合、2:8の法則に則ってテストコードを書くと良いそうです。
これは論文も出ている確かな数字らしく、筆者ももっと早く知りたかった内容です。
では、バグが潜んでいる2割はどこなのか。
確かに、言われると納得です。
また、どうテストするのかというのも大事なことで
CircleCIやJenkinsを使って自動化する、自動化したテストが丸一日かかる等がないようにする。
これはテストが重くなる問題にハマらないようにするということですね。
また、静的解析も役に立ちます。
テストが重くなる原因のひとつに、全部を自動化しようとすること。UIをなぞろうとすること。
攻めたい内容によって適切なテスト手法を取るということですね。
他にも、ためになる話を沢山されていたのですが詳しく知りたい方は、講演者の本を読んでみてはと思います。
ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方
https://www.amazon.co.jp/dp/B08TBD3LSS/ref=cm_sw_em_r_mt_dp_F2VEQSF822CSFB6MX1T8
まとめ
テスト駆動開発のメリット、デメリット、また、デブサミ2021でテストについて講演された内容をもとに、テストについて考えてみました。
これらをみる限り、テストコードはやはり書くべき！の一択ですね。
これらをみる限り、テストコードはやはり書くべき！の一択ですね。
