ユニットテストは労力に見合う価値があるか? [closed] 質問する

私たちのオフィスでは毎日、次のようなやり取りが行われます。

「いやあ、私はユニット テストが大好きです。何かの動作方法にたくさんの変更を加えた後、もう一度テストを実行して何も壊れていないことを確認できました...」

詳細は日々変化しますが、考え方は変わりません。ユニット テストとテスト駆動開発 (TDD) には、明らかな利点だけでなく、隠れた個人的な利点が数多くあるため、実際に実行してみるまで誰かに説明することはできません。

しかし、それを無視して、これが私の試みです!

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

2. TDD は、コーディングをいつ止めるべきかを知るのに役立ちます。テストを行うことで、現時点では十分な作業ができたという自信が得られ、調整を止めて次の作業に進むことができます。

3. テストとコードは連携して、より良いコードを実現します。コードが悪かったり、バグがあったりする可能性もあります。テストが悪かったり、バグがあったりする可能性もあります。TDD では、コードが悪かったり、バグがあったりする可能性が低いと見込んでいます。多くの場合、修正が必要なのはテストですが、それでも良い結果になります。

4. TDD はコーディングの便秘解消に役立ちます。大規模で困難な作業に直面したとき、テストを書くことですぐに作業を進めることができます。

5. ユニット テストは、作業中のコードの設計を実際に理解するのに役立ちます。何かを実行するためのコードを書くのではなく、コードに適用するすべての条件と、そこから期待される出力の概要を記述することから始めます。

6. ユニット テストでは、視覚的なフィードバックが即座に得られます。完了したときに緑色のライトが点灯する感覚は、誰もが好きなものです。非常に満足感があります。また、中断後に中断したところから再開することもはるかに簡単です。どこまで進んだかがわかるため、次に修正が必要な赤信号がわかるからです。

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

8. 「不完全なテストを頻繁に実行することは、まったく書かれない完全なテストよりもはるかに優れています」と言ったのは Fowler だったと思います。これは、コード カバレッジの残りの部分がひどく不完全であっても、最も役立つと思われるテストを書く許可を与えていると解釈しています。

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

10. ユニット テストはコードの再利用に役立ちます。コードとテストの両方を新しいプロジェクトに移行します。テストが再度実行されるまでコードを調整します。

私が関わっている仕事の多くは、ユニット テストがうまく行われていません (Web アプリケーションのユーザー インタラクションなど)。しかし、それでも、この職場では全員がテストに熱中しており、テストがうまくまとまったときに最も満足しています。このアプローチは、いくらお勧めしてもしすぎることはありません。