testing - アジャイルな方法：統合テストと機能テスト、またはその両方？

Question

私はしばらくの間アジャイルをやっているオフィスで働いています。私たちはプロジェクト管理にスクラムを使用し、XPのエンジニアリングプラクティスを組み合わせています。それはうまく機能し、私たちは常にレッスンを学び、プロセスを洗練しています。

テストの通常の方法について説明し、これをどのように改善できるかについてフィードバックをもらいたいと思います。

TDD：最初の防衛線 私たちは単体テストについて非常に信心深く、開発者も包括的なテストを作成し、常にモックでSUTを分離するのに十分な経験を積んでいると思います。

統合テスト 私たちが使用する場合、統合テストは基本的に、モックを使用しない単体テストと同じです。これは、単体テストをすり抜けたいくつかの問題をキャッチする傾向があります。これらのテストは、テストを意味のあるものにするためにシステムが特定の状態に到達する必要があるため、通常、スペックフレームワークのbefore_eachおよびセクションで多くの作業を行うため、読みにくい傾向があります。after_each

機能テスト 通常、これは構造化された手動の方法で行います。かっこいいSeleniumとWindmillで遊んだことがありますが、少なくともまだそこにはありません。

他の誰かがどのように物事をしているのか聞きたいです。統合テストまたは機能テストが十分に行われていれば、もう一方は無視できると思いますか？

score 24 · Accepted Answer

単体テスト、統合テスト、および機能テストは、同じコードを実行しますが、異なる視点から攻撃しています。違いを生むのはこれらの視点です。あるタイプのテストをやめると、その角度から何かがうまくいく可能性があります.

また、特に TDD を実践している場合、単体テストは実際にはコードをテストすることではありません。TDDのプロセスは、コードをより適切に設計するのに役立ちます。コードの最後に一連のテストという追加のボーナスを得ることができます。

継続的インテグレーションサーバーを実行しているかどうかについては言及していません。セットアップすることを強くお勧めします (ハドソンはセットアップが簡単です)。その後、コードのすべてのチェックインに対して統合および機能テストを実行できます。

score 5 · Accepted Answer

確かなセレンテストのセットは、顧客が品質に期待するものを実際にうまくまとめていることを私たちは経験しています. 要するに、私たちはこの議論をしてきました: セレンテストを書くことが単体テストを書くのと同じくらい簡単であるなら、単体テストにあまり焦点を当てるべきではありません。

そして、アプリケーションに何の影響も及ぼさないバグがどこかにある場合、誰が本当に気にしますか? しかし、現実の複雑さには常に問題があります。機能テストが正しいシナリオをキャプチャしていると確信していますか? アプリケーションの動作には直接見えない、他のシステムに起因する根本的な複雑さが存在する場合があります。

実際には、(selenese ではなく、適切なプログラミング言語を使用して) Selenium テストを作成することは、最初の問題をドリルスルーすると、非常に簡単で楽しいものになります。しかし、まだ単体テストを放棄するつもりはありません....

score 4 · Accepted Answer

単体テスト、統合テスト、機能テストはすべて異なる目的を果たします。他が高レベルの信頼性で実行されているという理由だけで、1 つを破棄しないでください。

score 4 · Accepted Answer

機能テストは真のテストであると言えます (これは単なる意見の問題です) 。つまり、アプリケーションの実際の使用を実際にシミュレートするテストです。このため、何があってもそれらを取り除かないでください。

まともなシステムが動いているようです。失うものがない場合は、すべて保持してください。

score 3 · Accepted Answer

私の現在のクライアントでは、単体テストと統合テストを実際には区別していません。ビジネスエンティティは、基盤となるデータレイヤー (独自の ORM フレームワークを使用) に大きく依存しているため、実際には、真の単体テストはほとんどまたはまったくありません。

ビルドサーバーはチームビルドの継続的インテグレーション (CI) でセットアップされており、遅いテスト (サーバー上で完全なテストスイートを実行するには 1 時間以上かかる) でこれが行き詰まるのを防ぐために、テストを「遅い」テストに分けました。 1 日に 2 回実行されるテストと、継続的インテグレーションの一部として実行される「高速」テストです。test-method に属性を設定することにより、build-server は 2 つの違いを認識できます。

一般に、「遅い」テストは、データアクセスを実行したり、Web サービスを使用したりする必要があるテストです。これらは、一般的な慣例により、統合テストまたは機能テストと見なされます。例: CRUD テスト、操作するオブジェクトのセットを必要とするビジネス検証ルールテストなど。

「高速」テストは単体テストに似ており、テストのために単一のオブジェクトの状態と動作を合理的に分離できます。

10 分の 1 秒以下で実行されるテストはすべて「高速」であると考えます。それ以外のものは遅く、おそらく CI の一部として実行すべきではありません。

開発の一部として使用するテストの「フレーバー」にこだわりすぎないようにすることに同意します (もちろん、受け入れ基準をテストとして表現することは例外です)。個々の開発者は、自分のコードに最適なタイプのテストを決定する際に判断を下す必要があります。ビジネスエンティティの単体テストを主張しても、CRUD テストの障害が明らかにならない可能性があります。

score 3 · Accepted Answer

単体テストは、段落内の単語のスペルが正しいことを確認することと似ています。機能テストは、段落が意味をなしているか、段落が含まれているドキュメント内で適切に流れているかを確認するようなものです。

score 1 · Accepted Answer

UIを介して何をテストするかを決定する方法として、Gojko Adzicの「フェイスセービングテスト」の概念が本当に好きです: http://gojko.net/2007/09/25/effective-user-interface-testing/

score 1 · Accepted Answer

私は、TDD のさまざまな種類のテストを分離しない傾向があります。私にとって、TDD は単体テスト駆動開発ではなく、テスト駆動開発です。そのため、私の TDD の実践では、単体テスト、統合テスト、機能テスト、受け入れテストを組み合わせています。これにより、一部のコンポーネントは特定のタイプのテストでカバーされ、他のコンポーネントは非常に実用的な方法で別のタイプのテストでカバーされます。

私はこのプラクティスの関連性について質問しましたが、簡単な答えは、実際には、ビルドごとに自動的に実行される高速/単純なテストと、実行頻度が低い低速/複雑なテストの分離であるというものでした。

score 1 · Accepted Answer

私の会社は機能テストを行っていますが、単体テストや統合テストは行っていません。私はそれらを採用することを奨励しようとしています. それらはより良いデザインを奨励し、すべてがうまくいっていることをより迅速に示すものだと思います. 機能テストを行う場合、単体テストは必要ですか?

score 0 · Accepted Answer

ユニット、統合、および機能テストはすべて異なる目的を果たすため、それらすべてを実行する必要があります。
私に属している重要な点は、書き込みテストの方法が非常に重要であり、TDD では不十分であるということです。BDD (動作駆動型開発) は良いアプローチを提供します...

testing - アジャイルな方法：統合テストと機能テスト、またはその両方？

10 に答える 10

Related

Reference