仕事でテスト駆動開発(以下 TDD)を行っていますが、テストにホワイトボックステストが含まれているため、メソッドを修正したらテストも修正することが多いです。
これってアジャイルじゃないよね？
TDD でホワイトボックステストを書く必要あるんだろうか？テストコードは、網羅基準とか考えないで、メソッドのふるまいを記述すればいい。ホワイトボックステストがあったら、リファクタしづらいです。
リファクタとテストを繰り返して、保守しやすいコードへと洗練させていくのが、TDD のメリットなのに。
追記
テスト手法について調べていたら、興味深い資料を見つけました。
一部引用。
- 業務ロジックは全てステートレスにしよう。
- 業務ロジックに状態はいりません。
- 条件分岐もいりません。ポリモーフィズムを使いましょう。
- ホワイトボックステストいりません。
- そもそも、ホワイトボックスの網羅基準を考えなければいけないようなクラスの設計自体がおかしいです。
- 2時間以内で作れないメソッドを作るのはやめましょう。
- DbC(Design by Contract)を使えば、同値分割・境界値テストはいりません。というかDbCでやってます。
- メソッドのロジックは事後条件で記述しましょう。ロジック自体の記述不要。
ここまで言い切られると痛快です。条件分岐をすべてポリモーフィズムに置き変えるのは、より複雑になりかねないけど。
