【テスト_1日目】単体テスト1冊目
こんにちは投資ロウトです。
背景
チームメンバーに自動テストのレクチャーをしていくことにしました。
※チームメンバーが自動テストができるようになるのがゴールです。
※週一の会議に向けての資料となるため、週一でこちらの単元は更新しようか検討しております。
進捗状況
少しずつ進めていっていますが、現在の進捗は以下になっています。
①要件定義：1冊
②設計：1冊
③システムビジネススキル：3冊 + 1冊目(keycloakが進行中(未マスト))
④インフラ：3冊
⑤フロントエンド：0冊、1冊(TailwindCSSが進行中(未マスト))
⑥AI：0冊、1冊(FastAPIが進行中(必須))
⑦テスト：0冊
なぜ単体テストを行うのか？
テスト者はテストの時間を抑えて、テストから最大の価値を引き出す必要性があるとのことでした。またこのようなプロジェクトは成長することが求められるような現場が多いとのことです。
逆に導入していないプロジェクトは膨大なバグと保守コストを潜在的に持っており、それによって失敗して行ってしまうとのことがあるとのことでした。
そしてテストの導入にあたっての費用対効果も見る必要があり、それをどのように分析していくかも重要とのことでした。
また多くのプロジェクトは単体テストや、統合テストだけではなく、網羅率も見られるようになっているとのことで、テストコード量はプログラム量に対しては1:1 〜 1:3の比率になるとのことです。
自分がスクラム開発をしていた時に、タスクとして単体テストや結合テストもある程度まとまった工数が積まれていたなと思い出しました。そういった意味でも、単体テストや結合テストを素早く書いていくスキルの必要性も高いんだなと改めて感じました。
話が戻りますが、単体テストが活躍するのは、追加機能などを導入することにより、新たなバグが生じてしまうのを防ぐために、テストを自動化させることによって、工数を削減させるのが目的とのことです。
また単体テストで実現したいのは、ソフトウェア開発を持続可能なものにするということでした。なぜかと言いますと、開発が進んでいくにつれて、関連のソースコードよりバグを検出するためのテスト工数が肥大化していくことで、開発のスピードが徐々に遅くなってしまうからといったことがあるようです。
これを聞いて改めて振り返ると、ある現場で現場の当初リリース後の保守や機能追加をした際に、追加機能を導入すると、その周辺のデグレのテストを行っていたことを思い出しました。つまり追加機能を入れるたびに現行のシステムが問題ないかの担保を行っていく必要がある(影響範囲によって肥大化する)とのことです。
しかし自動テストを導入することにより、その工数が発生しなくていいため、ずっと開発を行っていくシステムにとってはかなり有効なんだなと改めて感じました。
またこの開発スピードが落ちる現象をソフトウェア・エントロピーと呼ぶそうです。
また一部の機能を変更すると、ドミノ倒しのように、他の機能が次々と動かなくなってしまうような状態が起きることもあるそうです。そして最悪の場合、元の安定バージョンには動かせなくなるとのことでした。
これで過去の現場を思い出しましたが、自動テストを導入していない現場で、gitのtagコマンドを使ってバージョン管理をしていました。そしてあるプロジェクトリーダー格の方が、バージョン管理を行い、あるバージョンまで遡って確認をするようにしたいといったお話をされていたことを思い出しました。
プロジェクトによっては、Figmaだけで仕様については口頭で議論するだけといったこともありましたが、こういったように自動テストを導入していない現場では、色々バグが起きた際に、どこまではうまく行っていたかの確認のため、タグづけされたバージョンまで確認に戻っていたんだろうなと推察しました。
ただ自動テストがあれば、いつまで動かなかったというのは、自動テスト側で担保されるので、安定した状態でプロジェクトの機能が追加され、そして機能追加による追加テストの必要性も感じないといったことがありました。
テストの欠点
ただしテストをするためには、それだけの時間が必要となるといった欠点も挙げられていました。また自動テストを入れればいいというわけではなく、テストの質が悪ければ入れなくても変わらないといった状況に陥るといったこともあるそうです。
またテストを導入するだけではなく、維持するためのコストがかかることも改めて理解する必要があるとのことです。
【維持コスト】
・自動テストのリファクタリング
・機能の追加や修正されるたびにテストコードの修正
・テストが誤っていた際に、設計通りのテストになっているのか、それともバグを含んでいたかの確認
・既存実装を理解するために、テストコードを読む
現場によっては設計ドキュメントが少ないといった現場も少なからずあると思います。そういった意味でテストコード自体が設計の役割をするといったこともあるかもしれませんね。
網羅率について
テストの網羅率が高いからこそいいといったことではないとのことでした。100%カバレッジを通せていても、テストの質自体が悪ければあまり良くないといったこともあるそうです。
コードの網羅率 = 実行されたコードの行数 / 総行数
注意事項
# 下記のケースの場合、一行を行っているので、カバレッジが通るが2パターンを実施しないと、
# どちらともの条件を通らないので、注意とのこと。
return 条件式 ? true : false;
# ただし上記は分岐網羅率が上がらないので、きちんとテストされているかの確認は可能。
分岐網羅率 = 経由された経路の数 / 分岐経路の総数
またカバレッジを通ったとしても、その実行結果がどうだったかを検証しないと、意味のないテストになってしまうとのことです。
また網羅率をX%と定めるプロジェクトルールだったとしても、それ自身が開発の妨げになることもあるとのことでした。自分は過去に85%以上担保するといった現場もあったのですが、本の中では70%でも妨げになることはあるといったことを仰られていました。
テスト関連の質を良くしていく試み
・開発の中にテストを書くことが含まれていること
・コードの重要部分がテストされていること
・最小限の保守で最大の価値を生み出せること
ドメインモデル・・・業務で扱う(最小)単位でデータとロジックをひとまとめにして整理する技法
と一旦以上で学習を区切りたいと思います。チームメンバーのスキルアップが図れるように、焦らずコツコツ自分のペースで頑張っていきたいと思います。ご精読ありがとうございました。
Discussion