イエスマンの香りがする

ユニットテストにまつわる10の勘違い ｜ DevelopersIO

1. テストが無いほうがいいということはないですね。どんなひどいテストでも、無いよりはずっといい。

2. 時間をかければだれでもできる。仕様で決まったとおりの挙動をするかどうか、リストアップして書いていけばいい。

3. 悪い設計にしてしまったら、クラスをリファクタリングすることは受け入れなければならないが、なぜいい設計にできなかったのかをちゃんと反省しなければいけません。

4. わずかなコードの変更でも、ほとんど常にテストを行わねばならない。そのたびにいちいちすべてのテストを人間がするなど、ありえない。手作業テストと比較したら、コストが低いと言い切ってしまってかまわない。

5. 知能指数の低いプログラマこそ、ユニットテストをいっぱい書いて、品質を上げなければいけません。ただひとつの方法というほどじゃない。テストを書けばそれだけコードは信頼できるものなる。

6. 見た目のテストは難しい。何をもって正しく画面に映ってる、とするかは、悩ましい。しかし、モデルとビューの切り分けをしっかりして、できるだけビューのテストを少なくするとか、努力はできる。

7. 数字あそびにかまけてはいけないが、ソフトウェアの進捗の指標としては、これ以上のものはないと考えます。

8. テストを動かしてオールグリーンにすることは、快感なので、書いて満足という心配はしなくていいと思いますね。

9. 結合テストとユニットテストの境界線は、よくわかりません。new Main().invoke(new File("macro")); みたいな一行のユニットテストだって、見ようによっては結合テストに見えるかもしれません。

結局、私は、どんなプロジェクトにもユニットテストは有効と信じます！　自動テストが要らないソフトウェアなどソフトウェアと呼ぶに値せず、プロジェクトと呼ぶには小さすぎる！

アホかこいつは。
こういう偽TDD教の信者が一番厄介。
大元もまぁツッコミどころはあるし俺と考えが違うことはあるけど、コメントのほうは明確にダメ。
弊社にもこの手合いがいるので駆逐するための練習をしてみよう。