単体テストと受け入れテスト
あなたはどちらか一方ですか？または両方？
私の理解はユニットテストです：
- 開発者の観点からシステムを検証する
- 開発者がTDDを実践するのを助ける
- コードをモジュール化する
- 低レベルの粒度でエラーを検出するのに役立ちます
受け入れテスト：
- ビジネスおよびQC/QAの観点からシステムを検証する
- コードの内部動作に精通していない人々によって書かれていることが多いため、高レベルになる傾向があります
両方が必要だと感じています。ただし、冗長な作業を最小限に抑えるために、単体テストを受け入れテストに組み込むことをお勧めしますか？つまり、後者を前者と呼びます。反対方向に進むことは意味がありますか？
単体テストと受け入れテストについての一般的な考え、およびそれらを相互に関連させて管理する方法は何ですか？
受け入れテストと統合テストにより、コードが機能していて完全であるかどうかがわかります。単体テストでは、どこで失敗したかがわかります。
受け入れテストと統合テストで良い仕事をし、それらが合格した場合、コードは想定されているすべての機能を実装しており、機能しています。それは知っているのは素晴らしいことです（そうでないことを知っているのも素晴らしいことです）。しかし、それが機能していない場合、受け入れテストでは、何が間違っているのかについて多くの洞察を得ることはできません。機能の多くのユニットをテストするため、障害の鳥瞰図のようなものになります。これがユニットテストが輝くところです。優れた単体テストは、コードのどの部分で、何が間違っていたかを正確に示します。受け入れテストよりも十分な単体テストを記述したかどうかを知るのは困難ですが、対応する失敗する単体テストのない受け入れテストに失敗した場合は、その単体テストを記述します。
それはすべてテストの観点からです。そして、もちろん、TDDはテストに関するものではありません（そしてATDDはそうではありません）。設計の推進に関しては、受け入れテストでは広範なロードマップ（「ここに行きたい」）が提供され、単体テストでは次の交差点（「左折」）に進みます。この点で価値があり、その価値も互いに補完し合っています。
それらを混同しないでください。それらを間違えないでください。特に、単体テストは他のものに依存するべきではなく、受け入れテストを単体テストに依存させることにより、単体テストを制約するのは間違いです。もちろん、いくつかのフレームワークコードを共有できますが、独立している必要があります。
ただし、冗長な作業を最小限に抑えるために、単体テストを受け入れテストに組み込むことをお勧めしますか？
番号。
つまり、後者の[受け入れ]を前者の[ユニット]と呼びます。反対方向に進むことは意味がありますか？
気にしないでください。
受け入れテストはしばしば政治的なものです。あなたは、彼らの腸の本能に基づいて、受け入れるか拒否するかを決める人々にそれらを見せます。
次に、受け入れテストの有効性について議論します。
次に、作業範囲と次のリリースについて議論します。
受け入れテストは、一般的に技術的なものではありません。もしそうなら、あなたは正式なユニットテストを持っているでしょう、それはそれでしょう。
政治を巧みに操ろうとしないでください。それを受け入れます。起こらせよう。
Acceptance Test-Driven Development（ATDD）が「開発が始まる前にチーム全体で受け入れテストが作成され、合意される」ことを期待できます。しかし、事前に書かれたものは、せいぜいスペシャリストであり、最悪の場合は交渉可能であるという現実を反映する必要があります。
すべてのアジャイルメソッドの背後にある前提は、リリース可能なものに到達することだけに同意できるということです。その後はすべて交渉可能です。
すべてのテストファースト（TDD、ATDD、またはその他）の背後にある前提は、テストが強固な合意であることです。そうでないことを除いて。 TDD（またはATDD）メソッドを使用すると、原則としてテストに同意できます結果ですが、実際にはテストに同意していませんそれ自体。
テストを簡単に記述できない場合があります。さらに悪いことに、まったく書けません。 seem testableという結果に同意するかもしれませんが、定義が不十分であることが判明します。今何？これらは、開発を開始して詳細に到達するまでわからないことです。
すべてのテストが重要です。また、特定の種類のテストを他の種類のテストのスーパーセットまたはサブセットにすることはできません。それらは常に部分的に重複するセットです。何らかの方法で作業を節約するために結合しようとすると、時間の無駄になる可能性があります。
より多くのテストが他の何よりも優れています。すべてのテストの結合は、テスト間でサブセットとスーパーセットの関係を強制しようとするよりも価値があります。
単体テスト-私の特定の機能は、本来行うべきことを実行し、それ以上でもそれ以下でもありません。
受け入れテスト-私のアプリケーションは、想定されていることを行います。
例：二次関数の根を計算するアプリケーション。 a、b、およびcの入力を受け取り、ルートx1およびx2を返します。このアプリケーションは、2つの数値を加算し、2つの数値を減算し、2つの数値を乗算し、2つの数値を除算し、2つの数値の平方根を取得する関数によって作成されます。
ユニットテスト-除算および乗算関数が正しく動作すること、平方根が正しく動作すること、加算と減算が正しく動作することを確認します。
受け入れテスト-アプリケーションが2次関数の根を計算することを確認します。
私のアプリケーション全体は根を計算することなので、それを行う個々の関数がないので、根も計算する単体テストを持ってはいけません。
上記の要約として、
- 受け入れテストでは、正しいことを作成していることを確認します
- 単体テストでは、正しいことを構築していることを確認します
これらは、ある種のテストの問題に関する私の個人的な意見です。
ただし、冗長な作業を最小限に抑えるために、単体テストを受け入れテストに組み込むことをお勧めしますか？
私は2番目のS. Lottについてはこれを否定し、ユニットテストがある程度装備されており、いくつかのバグが通過する危険性があることを付け加えます。たとえば、ドロップダウンで誰かがいくつかの状態をテストする場合がありますが、すべてではない可能性があり、テスターが異なるデータを使用して潜在的なバグを発見する場合があります。
言い換えれば、後者を前者と呼んでください。反対方向に進むことは意味がありますか？
それらを一緒に結合することに注意してください。単体テストは機能の最小ビットのテストを表します。多くの場合、非常に小さいため、エンドユーザーはWebフォームを取得してCRMシステムにデータを入力するだけの数百のテストがあることを理解できません。受け入れテストは、アプリケーションのユーザーが望むものに関するものであり、より主観的である場合があります。 「これはきれいに見える？」対「これは正しく見えますか？」受け入れテストで「十分に良い」というマークがある場合がありますが、それは単体テストで動作するかどうかはわかりません。一般に、単体テストが失敗した場合、状況に応じてそれぞれが適切なオプションになる可能性があるため、誰かがコードを修正するかテストを削除するかを決定する必要があります。
単体テストと受け入れテストについての一般的な考え、およびそれらを相互に関連させて管理する方法は何ですか？
単体テストとは、最も単純なコードを検証することです。統合テストは可能ですが、すべての小さなピースがチェックされると、ピースの組み合わせが一緒に機能するため、これはレベルが高くなります。私が見た土曜日の朝の漫画には、「Voltron」やDevastatorを構成するConstructiconsのようなさまざまなトランスフォーマーのようなおもちゃがありました。受け入れテストは、一般に「今すぐアプリケーションでXを実行できますか？」というエンドユーザーの観点からのものです。何かがドアから出る前に「はい」と答えます。受け入れテストではいくつかのエラーケースがチェックされる場合がありますが、アプリケーションに入力される可能性のあるすべての組み合わせを徹底的にテストすることは一般的ではありません。ただし、単体テストでは境界条件やその他のランダムなケースがいくつか含まれる場合があります。