100パーセントのコードカバレッジの悲劇

物事がどのように変化するかは面白いです。 15年間、TDDの原則（テストによる開発、または以前はテストファーストアプローチと呼ばれていました）、または少なくとも開発者が単体テストを作成する必要があるという見解を遵守しました。 しかし最近、「これはテストする必要がある」ではなく、「なぜこのテストを書いたのですか？」

なぜそう

かつて、私がオフィスを歩いているときに、ある開発者が私を止めて、ユニットテストを手伝ってくれと頼みました。 彼はMockitoを使用してこのコードをテストするのに苦労しました。









私の答えは彼を驚かせたようです。 「これをテストする必要はありません。」



「もちろん必要です！」彼は答えた。 「すべてが機能していることを他にどのように知ることができますか？」



「これは完全に透過的なコードです。 そのようなものはありません：条件付き属性、ループ、変換はありません。 普通のミドルウェアです。」



「しかし、あなたがテストを受けなければ、誰でも来て、いくつかの変更を加え、すべてを壊すことができます！」



「この想像上のスラッカーや悪役が本当に来てすべてを台無しにしたとしても、聞いてください。対応する単体テストが失敗したとき、彼は何をすると思いますか？ 削除し、すべての問題。」



「まあ、テストを書く必要があったら？」



「その場合、私はそのような状況から抜け出すでしょう。」









「しかし、Mockitoは使用しないでください！」



「そして何？ Mockitoはここであなたを助けません。 それどころか、邪魔になります。 これにより、テストが簡単になり、読みやすくなりません。」



「しかし、Mockitoを使用してすべてのテストを実施することにしました！」



私の答えは：「...」



次回私が彼に会ったとき、彼は誇らしげに言った、彼はまだこのテストをモッキートで書くことができたと言った。 なんとか仕事をすることができたとき、あなたがどれほど満足しているか理解していますが、それでもなんとなく悲しかったです。

別の例

新しいアプリケーションの1つの高いコードカバレッジとBDD（行動ベースの開発）に対するフラッシュされた愛に触発された開発者から別の時間に私が呼ばれました。 コードを調べると、Cucumberでこのようなテストが見つかりました。











Cucumberを使用する人は、必要な補助コードの量に驚かないでしょう。















そして、これをすべてテストして、次のことをテストします。









はい、はい、シンプルなマップ検索。 私は、この開発者とかなり信頼できる関係を持っていて、率直に言って「無駄な時間を費やしました」と言いました。



「しかし、上司は私がすべてのクラスのテストを書くことを期待しています。」



「そしてそれはあなたに何の費用がかかりますか？」



「それは動き回っていますか？」



「さらに、これはBDDとは関係ありません。」



「知っていますが、すべてのテストをCucumberで行うことにしました。」



私の答えは「...」です。



ツールを自分のニーズに適合させることができたときの満足度はわかりましたが、それでもなんとなく悲しかったです。

悲劇とは何ですか？

悲劇は、2人の才能のある開発者（ チームインタビューのために喜んで彼らと一緒に行きます）が、そのようなテストのために時間を浪費していることです-テストは使用できず、次世代のIG開発者は作業状態を維持する必要があります。



悲劇は、仕事に適したツールを選択する代わりに、まったく不適切な人々に苦しめられ、その理由がわからないことです。



悲劇は、「グッドプラクティス」が一般的に受け入れられるようになると、それがどのようになったのか、どのような利点があり、そして最も重要なことには、それが必要とするコストを忘れるように見えることです。



これをすべて念頭に置く代わりに、私たちはあまり考えずに単純に自動的に適用します。その結果、非常に平凡な結果が得られます-ほとんどの利点を失い、同時に全額を支払うことがあります（ラップで）。 私の経験では、質の高い単体テストの作成は簡単ではありません。

それで、コード全体を処理する価値がありますか？

はい、これはすべての人が行うべきですが... 1つのプロジェクトのフレームワーク内でのみです。



極端な例として、単一の単体テストを使用しないプロジェクトがありますが、それらと連携するのがどれほど苦痛なのかはすでにわかっています。 しかし、反対の極端な経験をしている人はほとんどいません。コードを100％網羅し、すべての点でTDDを遵守する必要があるプロジェクトです。 単体テスト（特に、テストの最初のアプローチが実装されているもの）は優れた実践ですが、どのテストが有用で、どのテストが生産性を低下させるかを理解する必要があります。



覚えておいてください：何も私たちに費用はかかりません、ワンドはありません。 立ち止まって考えることは常に良いことです。