3層のアプリケーションでは、ビジュアル層のユニットテストが必要ですか？

Question

私のアプリでは、何十台ものPCがビジュアル層を実行しています。ビジネス層は、データベースを含むサーバー上に配置されます。

ビジュアル層では、基本的にビジネス層への呼び出しが含まれるユニットテストが本当に必要ですか？どんな特別な場合ですか？

Answer 1

UIテストは単体テストと呼ばれることはめったにありません。単体テストをテストするのは本当に難しいからです。これまでは、統合テスト、健全性テスト、機能テスト、または受入れテストと呼ばれていました。本質的には、システムが展開された後で（コードの単位ではなく）システムが動作することを確認します。しかし、これはあなたが達成しようとしていることに基づいて議論の余地があります。

UIテストを自動化するかどうかは、いくつかの要因によって異なります。開発者の時間当たりのレートは、しばしばQAのそれよりはるかに多い。だから、開発者が書いた自動化されたテストが組織全体に提供する価値を見なければならない。開発者が筆記テストに費やす時間は、システムに価値を加えることがより効果的です。しかし、QAはユニットの視点からシステムを見ることはほとんどありません。

しかし、開発者はシステムに関する知識が豊富であるため、テストを書くと品質が大幅に向上する可能性があります。テストは他の開発者のためのドキュメントとして機能し、意図を表明します。問題を早期に見つけ出す方が安価で、開発者が書くテストで最も魅力的な動機です。

したがって、2つのバランスを取る必要があります。あらゆる種類のUIテストの開発と保守は、特に分散環境では時間がかかり、複雑です。 UIテストはしばしば信頼性が低く、簡単に破損することがあります。環境のプロビジョニング、データベースのシード作成などを考慮する必要があります。また、自動テストを実行するのに十分なリソースがあるかどうかを検討する必要があります。それはまた高価になる。

アウトソーシングまたは手動で行うことで、コストを削減できます。後者は、自動化されたUIテストの作成、保守、実行、および診断のサイクルを経るよりも、毎回速く繰り返すことができます。

あなたのUIが安定している場合、システムが機能していることを確認するためにいくつかの受け入れテストを行うことは非常に有利です。 80％の時間で使用される20％の機能と、機能していないとシステムを役に立たなくするUIの機能を見てください。少なくとも、あなたの上司や顧客を含む20％の皆さんが、QAや顧客にテストをする前に働いていることを知っています。

Answer 2

テストのためのテストはテストする正しい理由ではありません。

Answer 3

ユニットテストは、コードをデプロイするすべての層で必要です。すべてのコードの完全性は、層に関係なく単体テストによって維持されるべきです。