-3

私は単体テストをあまり行っていません (TDD は行ったことはありません) が、少なくともビジネス層を単体テスト可能にしたいプロジェクトに取り組んでおり、できないように見えることがいくつかあります。理解する。

次の機能があるとします。

  • ユーザーに Excel ワークブックのファイル名を要求します
  • ワークブックの内容をグリッドにロードします
  • そのグリッドをフォームでユーザーに表示します。これは、ユーザーからのいくつかの入力も受け取ります
  • 機能が非同期的に更新されるプログレス バーを含むモーダル フォームを表示します...
    • そのような操作を実行し (閉じたフォームでのユーザー入力に基づいて)、大まかに言うと、グリッド コンテンツをデータベース テーブルにインポートします。

ここでは、ビジネス、データ、およびプレゼンテーションの問題を適切に分離できたと思います。フォームにはプレゼンテーション関連のコードのみが含まれ、データ操作は DAL (Linq to SQL) で行われるメソッド呼び出しであり、すべてがビジネス ロジック レイヤーで調整されます。依存関係はコンストラクターに注入されます。たとえば、フォームはDataTable、Excel ワークブックのファイル名ではなく、.

私が書くことができる（または書くべきForeach）テストについて考えると、ループが予想される反復回数を実行すること、GetMilimeterDimensions関数が実際に実行することを検証する簡単な（役に立たない？）もの以外は、単純に考えられませんインチをミリメートルに変換します (たとえば、 をGetMilimeterDimensions(new SizeF(1f,1f))返すテスト。これをよく読むと、関数の名前はConvertInchToMilimeterSizeF { Width = 25.4, Height = 25.4 }のようなものにする必要があるようです。まあ、これはBusinessMathクラスに静的メソッドとして属する関数のように感じます。悪い例だと思います。

ポイントは、テストしたいこれらの関数とメソッドはすべてprivate、最終的にクラスの COM 可視Execute()メソッドによって呼び出されるということです。public それは、テストのためだけに作成しなければならないということですか? または、私の機能の動作を、そのメソッドを公開するFunctionalityImplementationクラスに埋め込み、代わりに私の機能にこれらのメソッドを呼び出させるのですか? やり過ぎ感…

次に、DAL 呼び出しがあります。CRUD操作をモックし、予想される数のレコードが挿入されるかどうかを検証するテストを作成できるようにするために、いくつかのリポジトリパターンを実装する必要があります...しかし、それはビジネスレイヤーのテスト可能性を超えています.

それにもかかわらず、一部の VS プラグインで緑色のドットを取得するだけでも大変な作業のようです。テストが書かれたら、テストを壊すコード変更は、そもそもテストが書かれたことに感謝することを理解していますが、私は単体テストのポイントを完全に見逃していると思います.まったく役に立ちます。ここで私を助けてください。考えれば考えるほど、単体テストはその設計パターンを課す追加の作業にすぎないように思えます。

誤解しないでください（質問のタイトルは私が推測しています）、TDDの利点はわかります。単体テストの愛好家によって書かれたASP.NET MVCの本を読んだことがありますが、頭を包み込むことができないようですこれらの原則を単純な機能に適用する方法、ましてや COM から見えるライブラリ プロジェクト全体に適用する方法...

4

1 に答える 1

2

単体テストは重荷ではありません。多くの時間を節約し、エラーを防ぎ、リファクタリングを容易にして、コードを保守可能で柔軟に保ちます。

しかし、このプロジェクトには単体テストは必要ないかもしれません。

最も緊急の単体テストは、ビジネス ロジックが想定どおりに動作することを確認します。これは、ビジネス ロジックが複雑で、可動部分が多く、時間の経過とともに複雑になる可能性がある場合に非常に役立ちます。

 Person *p = ...sample person....;
 LoanRequest loan(p, $1,000,000);
 Assert(loan.CanBeApproved(bankPolicy,region,market,term),true);

ただし、基礎となるロジックが単純で明らかに正しい場合は、必須ではありません。

 Price=Total+Shipping;

同様に、すぐに短期間使用するための簡単なウィジェットを作成している場合、長期的なメンテナンスは最初の関心事ではなく、将来の共同作業者のためのドキュメントとしてのテストの役割はおそらく無関係です。ただし、製品を構築している場合は、これらのテストが必要になります。

一般に、単体テストは主に公共の行動に関係する必要があります。しかし、通常は非公開の中間結果を検証する方がはるかに簡単な場合があります。メソッドを公開したり、テスト用の特別なフックを提供したりすることは、ソフトウェアがあなたの考えどおりに動作し、他の人が変更を開始した後でもあなたの考えどおりに動作し続けるという信頼を得るために支払う妥当な代償です。

于 2013-03-20T18:17:44.200 に答える