並列開発について3

ちょっとだけ続きです。

並列開発が実現する上でちょっと悩まなくてはいけないものがあります。
画面単位の単体テストです。画面の動作と、イベント発生時の入力値による業務ロジックとを組み合わせてテストしてしまう、という試験方法は過去「今まで通りのやり方」として聞いた事がもっとも多いテスト手法でした。
私はこの方法の「操作ミス」と「再現するならもう一度操作」という手順があまり好きではないのですが、このやり方が良いと思われている方の「どうせ両方テストするのだからまとめてやってしまえば良い」という理屈も、言われてみればそうかなと思ったりもします。

しかし、UIと業務ロジックを分割して開発しようとした場合、「両方まとめてテスト」は結合試験までやらない事になります。つまり、単体試験の粒度が「今まで通りのやり方」から大きく変わってしまいます。それまで「今まで通りのやり方」に慣れていた人たちに、この差分を説明し、理解してもらい、納得してもらった上で足並みをそろえて実践というのは、非常に難しいと感じた事が過去多々ありました。

このアプローチは、まず結合度の低い設計にする必要ですが、同時にソフトウェアの品質をどう検証していくか、という点についても十分な考察が必要になります。個人的に、テスト・ターゲットが小さくて単純であればあるほどWhiteBoxテストが理想とされるような単体試験のような場合は良い、と思っているのですが。。。