黒柴的ソフトウェアテスト考 #9
コンポーネントテスト（単体テスト）に関する調査の考察#4
最後の考察は、以下のブログ記事に関するものとなる
著者は、TDDによるWPF開発を行ったチームに所属しているエンジニアで、該当記事の執筆時期は2016年くらいなので、開発時期はそれ以前と思われる
内容はリンク先の読んでいただくとして、黒柴の感想をまとめていきたい
結構、この記事は「なるほど」と思わされるところが多いので、テスト考#
7、#8に記載したブログ記事と比較して読んでいただきたい
黒柴が「なるほど」と思ったのは、TDDで実施するテストは、QAを目的としたテストとは別物という点である
著者が理解したTDDは、
「他機能から呼び出す前に、よりシンプルに抜き出した形で試しに動かしてフィードバックを得ることで、あるべき姿＝設計を練り、開発を前へ前へ進めていく＝駆動する」
ということだと思う
TDDを実施した結果としてテストコードが残るが、これはQAを目的としたテスト分析、テスト設計をベースに作成されたものではないため、そのままQAに適用できない
そのため、QAを目的としたテストを実施するためには、QAエンジニアが別途テストベースを元にテスト分析、テスト設計を行い、テスト項目を抽出し、テストコードを作成する必要があるとしている
すなわち、TDDはプログラム設計を練るための一つの手法であり、結果としてコード全体の可読性、メンテナンス性の向上を図ることができ、最終的には成果物全体の品質向上に寄与すると考えられる
しかし、TDDで実施するテストそのものが、QAに直接寄与するものではない
テスト考#7で記載されているように、
TDDの根幹？は、「テスト・コードで品質を担保する」ことにあると考えてます。
と、TDDで実施するテストが直接QAに寄与する（品質を確認する）と考えてしまうと、そのためにテストコード自体が正しいことを保証する作業（各種レビューなど）のコストが増えることになる
そのコストを軽減しようと作業の簡略化（レビューの省力など）などを考えてしまうと、TDDで実施するテストで、品質を確認することが難しくなる
今のところ、黒柴はTDDを説明した書籍を読んでいないので、この記事を執筆している時点（2023年）で、TDDがどのように説明されているのかを把握していない
ただ、「TDD」でインターネットを検索して抽出される記事のいくつかを見ていくと、
「テストコードを先に書いて、そのテストコードに見合うような実装とリファクタリングを繰り返す手法」
と説明されているものもあり、TDDで実施されるテストそのものが品質を保証するものではなく、あくまでもプログラム設計・実装における品質の向上を目指す手法として認識されているようだ
2010年前後では、「TDDをベースとしてテストコードを書けば書くほど、品質も上がり皆幸せになれる」と考えられていたが、その認識はどうやら変わったようである
この記事が気に入ったらサポートをしてみませんか？