6

Visual Studioに、クラスの各メンバーのテストを作成してもらいました。これが1つの例です：

/// <summary>
///A test for CloseCurrentTextLogFile
///</summary>
[TestMethod()]
public void CloseCurrentTextLogFileTest()
{
  Logger.CloseCurrentTextLogFile();
  Assert.Inconclusive( "A method that does not return a value cannot be verified." );
}

アサート文字列に基づいて、これをテストする方法を考えています...何かアイデアはありますか？

4

5 に答える 5

3

それが本当にテスト可能でない場合、それは実際には何もしないので、存在すべきではないと私は思います;）これに沿った何かがうまくいくかもしれません...

Assert.IsNotNull( Logger.File );
Logger.CloseCurrentTextLogFile();
Assert.IsNull( Logger.File );

または、のステータスを確認するか、終了する前に例外Logger.FileOpenStatusをスローするかどうかを確認しますが、終了した後は確認しません。その振る舞いがどんな行動を実行するかに依存するLogger.OpenFile(fname)何かがなければなりません。LoggerCloseCurrentTextLogFile()

于 2012-07-06T17:00:02.917 に答える
3

静的状態のメソッドは当然、それ自体をかなりテスト不可能にするため、私の提案は、静的メソッドからコードをリファクタリングすることに基づいています。

Loggerを、コンストラクターでIOオブジェクトを受け取るインスタンスクラスに変換します。これにより、IOオブジェクトをスタブ化でき、IOオブジェクトのCloseメソッドが呼び出されたことを表明できます。

これは、コードを100％テスト可能にしたい場合のみです。そうでなければ、私はMoに同意します。それがテスト可能でない場合は、強制テストを作成しないでください...それらは非常に脆弱になる傾向があります。結局、あなたはあなたのコードについて実用的である必要があります。多くの場合、ロガーは静的な状態を維持するのに役立ちますが、すでに述べたように、これらは非常にテストできない傾向があります。したがって、100％のコードカバレッジを取得するための単なる努力でテストを記述しないでください。 .100％には価格が付いてきます...

アップデート

これが、ユニットテストの独断的なPOVから真にテスト可能ではない理由です。作業単位をテストするのではなく、ロガーとロガーの依存関係（この場合はIOオブジェクト）をテストします。また、テストが遅くなり、環境のセットアップと状態が必要になります（最初に実際のファイルを開いて閉じる必要がありますよね？）。これらはすべて単体テストには適していませんが、統合テストには問題ありません...したがって、作成しているテストの種類によっても異なります。

于 2012-07-06T17:04:53.913 に答える
2

の状態を確認するか、Loggerこのメソッドを呼び出したためにエラーが発生しないロガーの他のメソッドを呼び出すことができます。このメソッドを呼び出さなかった場合は成功するはずです。

于 2012-07-06T16:53:54.600 に答える
2

どちらかはわかりませんが、次のことを試すことができます。関数は何かを実行することになっています（ファイルの書き込み、いくつかの変数の設定など）変数が書き込まれたか、ファイルが作成されたかを確認できます。

于 2012-07-06T16:54:05.120 に答える
1

Loggerクラスをモックアップして、CloseCurrentTextLogFileが呼び出されていることを表明できます。開いているログファイルがすべて閉じられていることを確認する必要があると主張する人もいるかもしれませんがLogger、メソッドではなくそれ自体をテストするため、個人的には同意しません。これは、開発者がシステムの設計を開始するときに自問する必要のある種類の質問です。アプリケーションをテストするにはどうすればよいですか。

于 2012-07-06T16:57:21.560 に答える