testing - なぜユニットテストメソッドを書くのですか?

Question

多くの人が、アプリケーションをテストするために何百行も書くのに多くの時間を浪費していることに気づきました。テストメソッドを書きやすくするためだけに、アプリケーションアーキテクチャを変更することがあります。を使用してメソッドをテストしてみませんか。つまり、私たちはユーザーのように行動し、さまざまな入力を与えて、結果が期待どおりかどうかを確認しようとします。

Answer 1

私はこれにもっと詳しく答えようとします。議論は、アプリケーションをクリックして期待どおりに機能するかどうかを確認するのではなく、大量の単体テストを作成する理由だと思います。ロジックは、テストする数千行のコードを記述するよりも、いくつかのボタンをクリックする方が時間がかからないということです。

私は公開されているウェブサイトを持ついくつかの会社で働いてきましたが、「クリックアラウンド」テストアプローチはひどいものだと言えます。理由：

1. スケーリングしません。重要なアプリケーションがある場合は、ユーザーとして行動することにより、リリーステストごとに何時間も費やします。

2. それは無駄です。あなたはあなた自身の偏見から何度も同じテストを実行することになります。あなたは常にあなたが最もよく知っている機能をテストし、あなたはルーチンに行き着きます。「私はこれをクリックし、次にそれ、そしてこれをクリックします...そしてアプリケーションは良いです！」いつも同じことをテストするのは時間の無駄です。

3. カバレッジは得られません。（2）と同様に...アプリケーションのすべての部分にヒットすると思いますが、ヒットしません。

4. 状態を再現するのは難しいです。ユーザーがページA、B、A、D、C、Aの順にクリックした後にのみ表示されるバグがある可能性があります。結局、システムをクリックすると興味深い状態になります。カジュアルなクリックでそれを再現することは決してありません。

5. バグを見つけたとしても、氷山の一角にぶつかっただけです。そのUI機能の下にあるどのメソッドが実際に問題であるかを理解することを楽しんでください。

私は何度も続けることができましたが、ユニットテストはこれらすべての問題にぶつかりました。テストでどれだけのコードカバレッジがあるかを示すツールもあります。