1

データベース、ファイルシステム、およびいくつかの外部Webサービスを実行して対話するWCFサービスがあり、結果を作成し、Xmlシリアライズして最終的に返します。

このソリューションのテストを書きたいのですが、その方法を考えています (すべて依存性注入と契約による設計を使用しています)。

私が取ることができる3つの主なアプローチがあります。

1) コード/メソッドの最小単位を選択し、それに対するテストを作成できます。1 つのクラスを選択し、その依存関係 (他のクラスなど) から分離します。品質は保証されますが、それらを書くには多くの時間がかかり、遅いです。

2) 外部システムとの対話のみをモック可能にし、要求が行われてから応答がシリアル化されて返されるまでの主なシナリオをカバーするいくつかのテストを作成します。これにより、クラス間のすべてのやり取りがテストされますが、すべての外部リソース アクセスがモックされます。

3) 外部 Web サービスとの対話、ファイル アクセス、データベース アクセスなどが行われるテスト環境をセットアップできます。その後、エンドツーエンドでテストを記述します。これには、環境のセットアップと、他のすべてのシステムへの依存が稼働している必要があります。

#1については、私が持っているすべてのメソッドまたはコードのテストを書くために時間/お金/エネルギーを投資しても意味がありません。つまり時間の無駄です。

#3 については、外部リソース/システムに依存するため、セットアップと実行が困難です。

＃2、私にとって最良の選択肢のようです。テストすべきものをテストするためです。私のシステムとそのすべてのクラスのみ、および他のすべての外部システムをモックします。

基本的に、単体テストを数年経験した後の私の結論は、単体テストを書くことは避けるべき無駄であり、代わりに分離されたシステムテストが投資に対する最良のリターンであるということです。

最初にテスト (TDD) を書き、次に製品コードを書くつもりだったとしても、やはり #2 がベストだと思います。

これについてどう思いますか。アプリケーションの小さな単体テストを作成しますか? 時間/予算/エネルギーを有効に活用する良い方法だと思いますか?

4

3 に答える 3

1

3 つすべてが重要であり、ユニット/統合/システム カテゴリのマトリックスであるさまざまなテスト タイプを対象としており、各カテゴリにポジティブ テストとネガティブ テストがあります。

コード カバレッジについては、ユニット テストの割合が最も高く、次に統合、システムの順に続きます。

また、テストの目的が検証 (最終的なユーザー/顧客の要件、つまり価値を満たすこと) であるか、検証 (仕様に従って書かれている、つまり正しいこと) であるかを検討する必要があります。

要約すると、答えは「場合による」です。私は、各活動の目標 (価値) から始めて、最終的に全体を許可する手段をその活動に適用する、検証と検証 (つまり、テスト) の SEI CMMi モデルに従うことをお勧めします。継続的な改善の対象となるプロセス。このようにして、方法から何を、なぜを分離し、特定の環境 (生命維持システムやその日のつぶやき、お気に入りの叔母、アプリなど) に対する時間と価値のタイプの質問に答えることができます。 ）。

于 2013-03-28T21:18:26.577 に答える
1

品質について話したい場合は、次の 3 つすべてが必要です。

  1. 単体テストにより、コードが想定どおりに動作することを確認し、エッジ ケースを明らかにし、リグレッションを支援します。あなた（開発者）はそのようなテストを書くべきです。
  2. コンポーネントが互いに正しく通信するかどうかなど、プロセス全体の正確性を検証するための統合テスト。繰り返しになりますが、開発者はそのようなテストを作成します。
  3. 本番環境に似た環境でのシステム全体のテスト (いくつかの制限があります。クライアント データベースにアクセスできない場合もありますが、ローカル マシンには正確なコピーが必要です)。これらのテストは通常​​、専任のテスターに​​よって (多くの場合、アプリケーション コードとは異なるプログラミング言語で) 作成されますが、もちろん、あなたが作成することもできます。

2 番目と 3 番目のタイプのテスト (統合とシステム) は、小さなコンポーネントのエッジ ケースをテストするには、多大な労力を要します。これは通常、単体テストが必要なものです。テスト済みで検証済みの正しいモジュールを接続すると何かが失敗する可能性があるため、統合が必要です。そしてもちろん、システム テストは、開発中に毎日行ったり、割り当てられた人 (手動テスター) に任せたりするものです。

リストから選択したタイプのテストに行くことは、ある程度はうまくいくかもしれませんが、完全なソリューションや高品質のソフトウェアにはほど遠い.

于 2013-03-28T20:24:06.820 に答える
0

要約: #2 (統合テスト) が最も論理的に思えますが、さまざまなテストを使用して、最も必要とするコードベースの部分を最適にカバーすることを躊躇してはなりません。「すべて」のテストを行うための射撃は、価値のある目標ではありません。

ロングバージョン

開発者がユニット\統合\システム テストを採用することは、テストされるコードのすべてのチャンクに対して努力することを意味すると確信している考え方があります。テストカバレッジがまったくないか、「すべて」をテストすることにコミットしています。この二者択一の考え方は、常にあらゆる種類のテスト戦略を採用することを非常に高くつくように思わせます。

真実は、コード\関数\モジュールのすべての行を強制的にテストすることは、すべてのコードをできるだけ速く書くのと同じくらい健全です. 時間と労力がかかりすぎて、ほとんどの場合、利益はほとんどありません。もう 1 つの真実は、重要なプロジェクトで真の 100% カバレッジを達成することは決してできないということです。

テストはそれ自体が目的ではありません。これは、最終製品の品質、保守性、相互運用性などを可能な限り最小限の労力で達成するための手段です。

それを念頭に置いて、一歩下がって、あなたの特定の状況を評価してください。「このソリューションのテストを書きたい」のはなぜですか? 今日のプロジェクトの全体的な品質に不満がありますか? 高い回帰率を経験したことがありますか? 一部のモジュールがどのように機能するか (さらに重要なことに、モジュールにどのようなバグがあるか) について、おそらく確信が持てませんか? 正確な目標が何であれ、特定の課題をもたらす作品を選択し、それらに注意を向けることができる必要があります。それらの要素に応じて、適切なテスト アプローチを選択できます。

特にトリッキーな関数やクラスがある場合は、単体テストを検討してください。複数の相互作用を理解するのが難しい複雑なアーキテクチャに直面している場合は、統合テストを作成して、最もトリッキーなシナリオの明確なベースラインを確立し、問題の原因をよりよく理解することを検討してください (おそらくいくつかのバグを一緒に洗い流すでしょう)。道）。システム テストは、よりローカライズされたテストで問題が解決されない場合に役立ちます。

特定のシナリオについて提供した情報に基づいて、外部向けの単体テスト\統合テスト (#2) が最も有望に見えます。多くの外部依存関係があるように見えるので、これが複雑さのほとんどが隠れている場所だと思います。包括的な単体テスト (#1) は #2 のスーパーセットであり、すべての余分な内部要素が疑わしい価値を持っています。#3 (完全なシステム テスト) では、おそらく、外部のエッジ ケースやエラー状態を希望どおりにテストすることはできません。

于 2013-07-05T05:55:42.740 に答える