あなたはどちらに賛成ですか？または両方？
私の理解はユニットテストです：
受け入れテスト:
どちらも必要だと感じています。しかし、冗長な作業を最小限に抑えるために、単体テストを受け入れテストに組み込むことは良い考えでしょうか? つまり、後者が前者を呼び出すようにします。反対方向に行くことに意味はありますか？
単体テストと受け入れテストについて、一般的にどのように考えていますか? また、それらを相互に関連させて管理する方法を教えてください。
受け入れテストと統合テストにより、コードが機能して完全であるかどうかがわかります。単体テストは、どこで失敗しているかを教えてくれます。
受け入れテストと統合テストでうまく機能し、合格している場合、コードは想定されているすべての機能を実装しており、機能しています。それを知ることは素晴らしいことです (そうではないことを知ることもまた素晴らしいことです)。しかし、それが機能しない場合、受け入れテストを行っても、何が問題なのかについての洞察はあまり得られません。機能の多くのユニットをテストするため、失敗の鳥瞰図のようなものになる可能性があります。ここで単体テストが活躍します。優れた単体テストは、コードの正確な部分で何が問題だったのかを正確に教えてくれます。受け入れテストよりも十分な数の単体テストを作成したかどうかを判断するのは困難ですが、対応する失敗した単体テストがない受け入れテストの失敗がある場合は、その単体テストを作成するときです。
以上がテストの観点からの説明です。もちろん、TDD はテストに関するものではありません (ATDD もそうではありません)。設計の推進に関して、受け入れテストは大まかなロードマップ (「行きたい場所はここです」) を提供し、単体テストは次の交差点 (「左折」) に導きます。この点で両方とも価値があり、繰り返しになりますが、それらの価値は互いに補完し合っています。
それらを混同しないでください。それらを混同しないでください。特に、単体テストは他に依存すべきではありません。受け入れテストを単体テストに依存させることで単体テストを制約するのは間違いです。もちろん、いくつかのフレームワーク コードを共有できますが、独立している必要があります。
しかし、冗長な作業を最小限に抑えるために、受け入れテストに単体テストを組み込むことは良い考えでしょうか?
いいえ。
つまり、後者の【受付】が前者の【ユニット】を呼び出してもらう。反対方向に行くことに意味はありますか？
気にしないでください。
受け入れテストはしばしば政治的なものです。直感に基づいて、受け入れるか拒否するかを決定する人々にそれらを示します。
次に、受け入れテストの有効性について議論します。
次に、作業範囲と次のリリースについて議論します。
受け入れテストは一般的に技術的なものではありません。もしそうなら、正式な単体テストがあり、それがそれです。
政治を巧みに操ろうとするな。抱きしめて。起こらせよう。
受け入れテスト駆動開発 (ATDD) が「開発開始前に受け入れテストを作成し、チーム全体で合意する」ことにつながることを期待できます。しかし、事前に書かれていることは、せいぜい偽りであり、最悪の場合は交渉可能であるという現実を反映する必要があります.
すべてのアジャイル手法の背後にある前提は、リリース可能なものに到達することにのみ同意できるということです。それ以降はすべて応相談です。
すべてのテスト ファースト (TDD、ATDD、またはその他のもの) の背後にある前提は、テストが鉄壁の合意であるということです。そうではないことを除いて。どの TDD (または ATDD) 方式でも、テスト結果には原則として同意できますが、テスト自体には同意していません。
テストを簡単に記述できない場合があります。さらに悪いことに、まったく書き込めません。テスト可能に見える結果に同意するかもしれませんが、定義が不十分であることがわかります。今何？これらは、開発を開始して詳細に到達するまで知ることができないものです。
すべてのテストは重要です。また、特定の種類のテストは、他の種類のテストのスーパーセットまたはサブセットになることはできません。それらは常に部分的に重複するセットです。どうにかして作業を節約するために組み合わせようとすると、時間の無駄になる可能性があります。
より多くのテストは何よりも優れています。すべてのテストを結合することは、テスト間にサブセットとスーパーセットの関係を強制しようとするよりも価値があります。
単体テスト - 私の特定の関数は、本来の機能を実行しますが、それ以上でもそれ以下でもありません。
受け入れテスト - 私のアプリケーションは本来の機能を果たしています。
例: 二次関数の根を計算するアプリケーション。a、b、および c の入力を受け取り、ルート x1 および x2 を返します。このアプリケーションは、2 つの数値の加算、2 つの数値の減算、2 つの数値の乗算、2 つの数値の除算、および 2 つの数値の平方根を取るために私が作成した関数によって構築されています。
単体テスト - 除算と乗算関数が正しく機能すること、平方根が正しく機能すること、加算と減算が正しく機能することを確認します。
受け入れテスト - アプリケーションが二次関数の根を計算することを確認します。
私のアプリケーション全体はルートを計算するためのものであるため、ルートを計算する単体テストは必要ありません。これを行う個別の関数がないためです。
これらは、いくつかの種類のテストの問題に関する私の個人的な意見です。
しかし、冗長な作業を最小限に抑えるために、受け入れテストに単体テストを組み込むことは良い考えでしょうか?
私はこれについてS. Lottのノーを支持し、ユニットテストがある程度不正に操作され、バグが通過する可能性があるという危険性があることを付け加えます。たとえば、ドロップダウンでは、テスターが潜在的なバグを発見するためにさまざまなデータを使用する可能性があります。
つまり、後者が前者を呼び出すようにします。反対方向に行くことに意味はありますか？
私はそれらを一緒に結合しないように注意します。単体テストは機能の最小部分のテストを表し、多くの場合非常に小さいため、Web フォームを取得して CRM システムにデータを入力するためだけに何百ものテストがあることをエンド ユーザーが理解できないほどです。受け入れテストは、アプリケーションのユーザーが何を求めているかについてのものであり、より主観的なものになる可能性があります。たとえば、「これはきれいに見えますか?」などです。対「これは正しいですか？」単体テストで機能するかどうかわからない受け入れテストでは、「十分」というマークが付く可能性があります。通常、単体テストが失敗した場合、コードを修正するか、テストを削除するかを誰かが決定する必要があります。これは、状況に応じてどちらも適切な選択肢になる可能性があるためです。
単体テストと受け入れテストについて、一般的にどのように考えていますか? また、それらを相互に関連させて管理する方法を教えてください。
単体テストは、コードの最も単純な部分を検証することです。統合テストはあるかもしれませんが、すべての小さなピースがチェックされたら、ピースの組み合わせが一緒に機能するので、これはより高いレベルです。または、Devastator を形成した Constructicons のようなさまざまなトランスフォーマー。受け入れテストは一般に、「アプリケーションで X を実行できますか?」というエンド ユーザーの観点から行われます。何かがドアの外に出る前に、「はい」という答えを持っています。一部のエラー ケースは受け入れテストでチェックされる場合がありますが、アプリケーションに入力できる可能性のあるすべての組み合わせを徹底的にテストすることは一般的ではありません。ただし、単体テストは、境界条件やその他のいくつかのランダムなケースをカバーする場合があります。