[解決済み] ユニットテストは努力に値するか？[クローズド］

質問

私が所属するチームでは、ユニットテストを開発プロセスに統合しようと取り組んでいますが、懐疑的な人もいます。チーム内の懐疑的な開発者にユニットテストの価値を納得させる良い方法は何でしょうか？私の具体的なケースでは、機能追加やバグの修正に合わせてユニットテストを追加しています。残念ながら、私たちのコードベースは簡単にテストできるようなものではありません。

どうすればいい？

私たちの会社では、毎日こんなやりとりがあります。

私はユニットテストが大好きなんです。

細部は日々変わるが、心情は変わらない。ユニットテストとテスト駆動開発（TDD）には、明白な利点だけでなく、隠れた個人的な利点がたくさんあり、実際にやってみるまでは、誰かに説明することはできません。

しかし、そんなことはお構いなしに、私の試みはこうだ!

1. ユニットテストは、コードに大きな変更をすばやく加えることを可能にします。テストを実行したからには、それが動作することが分かっているわけで、必要な変更を加えるときには、再びテストを動作させる必要があります。これは時間の節約になります。

2. TDDは、コーディングをやめるべきタイミングを悟るのに役立ちます。テストをすることで、「もうこれで十分だ」と自信を持ち、手を加えるのをやめて次のことに移ることができるのです。

3. テストとコードが連動して、より良いコードを実現する。あなたのコードは悪い/バグだらけかもしれません。テストが悪い/バギーである可能性があります。TDDでは、以下の可能性に賭けています。 両方 バグの可能性は低くなります。多くの場合、修正が必要なのはテストの方ですが、それでも良い結果です。

4. TDDはコーディングの便秘を解消します。大きくて大変な仕事を前にしたとき、テストを書くことですぐに動き出すことができます。

5. ユニットテストは、あなたが作業しているコードの設計を本当に理解するのに役立ちます。何かをするためにコードを書くのではなく、コードに課されるすべての条件と、そこから期待される出力の概要を説明することから始めるのです。

6. ユニットテストでは、視覚的なフィードバックを即座に得ることができます。とても満足感があります。また、中断した後、中断したところから再開するのも簡単です。というのも、次の赤信号を修正する必要があるかどうかがわかるからです。

7. 一般的に信じられていることとは異なり、ユニットテストは、2倍のコードを書くことや、より遅いコーディングを意味するものではありません。一度コツをつかめば、テストなしでコーディングするよりも速く、より堅牢になります。テストコード自体は、通常、比較的些細なものであり、あなたが行っていることに大きなオーバーヘッドを追加することはありません。これは、実際にやってみないとわからないことです :)

8. ファウラーだったと思うが、「不完全なテストを頻繁に実行することは、全く書かれない完璧なテストよりもずっと良い」と言った。私はこれを、たとえ私のコードカバレッジの残りがひどく不完全であったとしても、最も有用と思われる場所にテストを書くことを許可してくれていると解釈しています。

9. 優れたユニットテストは、何かが何をすべきかを文書化し定義するのに役立ちます。

10. ユニットテストは、コードの再利用に役立ちます。あなたのコード と テストを新しいプロジェクトに移します。テストが再び実行できるようになるまで、コードをいじってください。

私が関わっている多くの仕事は、ユニットテストがうまくいきません（ウェブアプリケーションのユーザーインタラクションなど）が、それでもこの店では全員がテスト感染者で、テストが結びついたときが一番幸せなのです。このアプローチはとてもお勧めできるものではありません。