0

コア ライブラリのユニット テストを作成中です。

クラスの 1 つは、時間の経過に伴うコンピューター パフォーマンスのワークロードを (平均として) 測定し、いくつかの重みを適用し、数値を吐き出すことができます。

現在、平均を実行して重みを適用するために使用するクラスは、簡単に単体テストできます。(いくつかの平均を投入し、既知の結果と比較します)。テストするのがそれほど簡単ではないのは、クラス自体の目的Workloadです。これには、たとえば 50% の使用率でマシンを強制的に使用し、既知の加重調整された 50% の平均値と照合する必要があるためです。

もちろん、マシンの使用率が 50% であると「ふりをして」結果を比較できることは承知していますが、単体テストが実際の使用率 50% に対して実際にテストされているわけではありません。

他にどのような「困難な」テスト ケースに出くわしましたか? それらが不可能でない場合、それを解決するためにどのような創造的な方法を採用しましたか?

4

1 に答える 1

1

MsgBoxWinForms アプリケーションで単純な (または任意のモーダル ウィンドウ) が表示されることをテストしたことがありますか? 最近のプロジェクトでは、Win32 ハンドルとマルチスレッド テスト ケースと格闘し、ダイアログが画面に表示されることを一貫して検証しようとしました (モーダルであるため、メインのテスト スレッドから実行することはできません)。テストは時々うまくいきますが、「正当な」理由もなく断続的に失敗する傾向がありました (たとえば、何らかのバックグラウンド プロセスが原因で、テスト中にウィンドウのフォーカスが失われました)。

この場合、C# デリゲートの機能を使用して、基本的に への静的呼び出しをモックしましたMsgBox.Show()。次のようなデリゲートを宣言することによって

public delegate DialogResult ShowDelegate(string text, string caption);

本番環境で使用できnew ErrorMessageHelper(MsgBox.Show)、テストは次のようになりました

[TestFixture]
public class ErrorDialogHelperTest
{
    [Test]
    public void UsesShowDelegateToDisplayMessage()
    {
        bool delegateWasCalled = false;
        ShowDelegate mockShowDelegate = delegate(string text, string caption)
        {
            Assert.AreEqual("the expected message", text);
            Assert.AreEqual("the expected title", caption);
            delegateWasCalled = true;
        };

        ErrorDialogHelper helper = new ErrorDialogHelper(showDelegate);

        helper.ShowErrorMessage("the expected message", "the expected title");
        Assert.IsTrue(delegateWasCalled);
    }
}

もちろん、実稼働インスタンスを実際に で構築したことを確認するために、さらにテストを行いましたMsgBox.Show。この例では を使用MsgBoxしていますが、同様の手法を使用して、すべてのモーダル ウィンドウの表示をテストしました。

テストが困難なもう 1 つの古典的な例は、コードでウォール クロックの日付と時刻を使用する必要がある場合です。繰り返しますが、解決策は、テストから制御できる偽の時計を導入することです。どちらの場合も、基礎となるフレームワークまたはシステム実装が正しく機能することに依存しており、すべてが正しく接続されていることのみをテストします。それが合理的なリスクであるかどうかは、ケースバイケースで判断する必要があります。

于 2013-04-24T05:57:48.640 に答える