コンポーネントテスト（単体テスト）に関する調査の考察#3

3番目の考察は、以下のブログ記事に関するものとなる

著者は、TDDを適用したプロジェクトをコントロールしているリーダーで、該当記事の執筆時期は2015年初頭だが、開発時期は2009年くらいと思われる

内容はリンク先の読んでいただくとして、黒柴の感想をまとめていきたい
著者自身が、TDDによる開発を実施した結果、壁となったのは以下の7点だと思う

1. 一部テスト（HTTPのリクエスト／レスポンス）について、既存のテスト環境のみでは弱く、別途ヘルパーを作成するなど手間取った

2. テストコードで何を担保するのかを策定するのに手間取った（最終的にはインテグレーションテストを手厚くした）

3. テストコードを書くほどもない機能にもテストコードを書くため、コピペが増え、作業者のモチベーションが低下した

4. テストコードをテストしないまま構成管理ツールに登録する作業者が続出したため、テストコード自体のエラーが発生した

5. テストコードの粒度について、作業者間のばらつきが大きく、それを統一するためのコードレビューに時間がかかった

6. ステータス、そのほかの状況によって処理結果が変わる機能のテストコードを書くことに手間取った

7. 仕様変更にシステム開発が追い付かなくなり、テストコードを書く時間がなくなったことから、TDDをあきらめた

実施されたプロジェクトは、アジャイル開発の手法を取っているようで、TDDで作成されたテストコードは、CI（継続的インテグレーション）ツールを使用しての自動テストに組み込んでいるようだ

興味深いなと思ったのは、7つ目の壁である
そもそも、ウォータフォール型の開発比較して仕様変更を許容しやすいと言われるアジャイルという開発手法を取っているにも関わらず、「仕様変更にシステム開発が追い付かなくなり、テストコードを書く時間がなくなった」としている
自動テストを取り入れていると思われるため、仕様変更に伴うテストコードのメンテナンスが間に合わなくなっているのだろうなと想像できる

少し自動テストのことについて、考えてみたい
JSTQB カンファレンス in 2023 Autumnの中でも、自動テストに関する質問があった
質問内容は、「どのような場合に自動テストを取り入れるべきか？」というもので、回答としては「あらかじめリグレッションテストのように、同じテテストを何回も繰り返すことが予定されている場合に、検討すべき」とされていた

作成したテストコードをCIツールにより自動で駆動するというのは、テストに費やす工数を削減できるという点では、魅力的である
しかし、それはリグレッションテストのように、ある機能の修正が他の修正対象ではない部分に影響を及ぼしていないことを確認するような場合に限定されるのではないか？

また、ソースの不具合を修正したことの確認でも、有効だと考える
なぜなら、この場合テストコードが正しい（本来の仕様と合致している）ため、テストコードの修正は発生しない

しかし、仕様変更が発生した場合はどうか？
変更した仕様に合わせて、要件定義書、設計書の修正、それらをテストベースとしたテスト設計のやり直し、テスト設計を元にしたテスト項目の抽出、テストコードの修正、およびこれらの確認のためのレビューが発生する
自動テストを有効に活用するためには、これらテストコードのメンテナンスも必須となるため、内容としては簡単（対応工数が少ない）と思われる仕様変更にも多大なコストがかかる可能性を認識しておくべきだろう

とかくエンジニアは、新しいものに興味を示して、それを取り入れてみたいと思うものである
黒柴自身も自動テストを取り入れてみたいと考えたことも過去にはあった
結果として、取り入れたが有効に活用できていないということもあるので、実施前にそのメリット・デメリットを整理して、適用の可否について確認する必要があると考える