web-dev-qa-db-ja.com

到達できないコードをテストするにはどうすればよいですか？

あなたの会社がカスタマイズ可能なテキストが付属するソフトウェアを販売していて、あなたのチームの仕事はそれをカスタマイズすることだとしましょう。クライアントエンゲージメントには、クライアントがすべてのテキストリソースを指定し、チームが完全なテストサイクルを保証する契約が含まれます。

コードのどこかに、次のようなロジックがあります。

var response = proxy.Foo(request);
if (!response.IsOK)
{
    switch (response.ErrorCode)
    {
        case Constants.BadProfile:
            DisplayError(Resources.BadProfile);
            break;
        case Constants.BadRequest:
            DisplayError(Resources.BadRequest);
            break;
        default:
            DisplayError(Resources.GeneralError);  //Should never happen
            break;
    }
}

コードの記述方法に基づいて、3番目のエラーを引き起こすデータ条件を生成することは文字通り不可能です。しかし、エンジニアリングチームは、将来のコードの欠陥が発生した場合に備えて、またはクライアントが古く、プロキシが新しく見慣れないエラーをスローする状況を防ぐために、そこに配置しました。

つまり、クライアントは3つすべてのエラーメッセージリソースをカスタマイズしており、QAはそれら3つすべてをテストしたいと考えています。

一般的なエラーリソースが正しいことを確認するために、QAがテストを要求するのは妥当でしょうか。彼らはどのようにしてそのエラーを引き起こす可能性がありますか？

または、定義可能な許容基準のない機能を指定しているため、エラーメッセージを含めることは要件の誤りですか？

注：この例のproxyはサードパーティのサービスであるため、予期しないエラーをスローするようにリグすることはできません。もちろん、クライアントコードを変更してエラーを強制することもできますが、最終的には本番環境で実行されるコードベースをテストしません。

編集：

この場合の「プロキシ」は、WCFまたはRESTクライアントではありません。ブラックボックスバイナリDLLです。懸念事項の分離、依存関係の注入、および傍受するための便利なトランスポートはありません。努力なしに結果をシムする場所はどこにもないので、英雄的であるので、テストの信頼性とそのようなEdgeケースの努力の支出を損ないます。

一方、QA 100％の統計を達成するためだけにバックストップを完全に削除することは、少し常識に反する、少しディストピア的であるように見えます。

機能を「非表示」にして顧客に知らせることはできませんが、テキストには各顧客に固有の貴重なサポート情報が含まれています。

testinglanguage-agnosticfunctional-testing
1
John Wu

真剣に、そのプロキシを模倣します。これは、テストするシステムの境界です。

次のいずれかを作成します。

  • サードパーティシステムを完全に置き換えるフルスタブ。さまざまな方法でリクエストを処理できるように十分にスマートにして、すべてのオプションを探索できるようにします。
  • コードとサードパーティのコードの間に位置するスパイ。条件付きでリクエストをパススルーし、条件付きで別のレスポンスを返すように十分にスマートにします。相互作用をログに記録できる必要があります。これにより、すべてのオプションを調べることができますが、アプリケーションがどのように統合されるかを確認するウィンドウも提供されます。

これが自分でできない場合は、エンジニアリングチームにプッシュしてください。彼らはcanテスト範囲を与える境界を書きます。さらに、単体テストを介したテストが容易になります。

そのプロキシが明確に定義されたプロセス間通信プロトコルの表現である場合、既製のスパイ/スタブが多数あるため、幸運です。

サードパーティのライブラリ/非標準プロトコルによって提供される場合、開発者は言語抽象化メカニズムを使用して、ファサード/アダプターを提供し、サードパーティの代わりにスタブ/スパイバージョンを使用する方法を提供する必要があります。パーティーライブラリーオプション。

6
Kain0_0

これらすべてのエラーメッセージが正しくカスタマイズされているかどうかをテストすることだけが必要な場合は、数か月の作業を費やしてすべてのエラー状況のテストシナリオを作成し、アプリケーションを表示するよりも効率的な解決策があります。 「実際の」エラーによるカスタマイズされたテキスト。代わりに、

  • エンジニアリングチームに追加の簡単な"test Customize error texts）機能を提供するように依頼してください。これにより、ダイアログボックスまたはダイアログボックスと同様のサイズとスタイルのリソースから利用可能な各エラーメッセージを表示できます。エラーが発生した場合に定期的に表示されるフォーム。
  • 比較のために元のテキストとカスタマイズされたテキストをすばやく切り替えることもできるように、機能を構築するように依頼します。

これにより、質問のスニペットなどのコードを変更する必要がなくなり、プロキシをモックアウトする必要がなくなり、すべて（QAと同様に）簡単にすべてをテストできるようになります。カスタマイズ。そしておまけとして、そうでなければ（ほとんど）到達できないコードでのみ表示されるエラーテキストのカスタマイズをテストすることは簡単になります。

1
Doc Brown

スイッチケースをテストする方法は？ディスパッチはオブジェクトによって実行できます。

switch (response.ErrorCode)
{
    case Constants.BadProfile:
        DisplayError(Resources.BadProfile);
        break;
    case Constants.BadRequest:
        DisplayError(Resources.BadRequest);
        break;
    default:
        DisplayError(Resources.GeneralError);  //Should never happen
        break;
}

  • ケースをディクショナリ/マッピングに切り替え、エラーコードを変更します

    DisplayError(errorCodeToMessage.getDefault(response.ErrorCode, Resources.GeneralError))

  • オブジェクトを要求するために、等価性のマッピングをリファクタリングします。次に、その前にエラーコードを設定できます。

    response.getErrorResourceId()
  • GUIを呼び出す低レベルのロジックが好きではありません。その間に私が明示的に書いたいと思っている非常に多くの抽象化と思考が存在する可能性があります。

考えて、私の完璧なコードは次のようになります：

var response = proxy.Foo(request);
if (response.isOK()) {
    ...
} else {
    displayResponseError(response)
}

void displayResponseError() {
    errorCode = response.errorCode
    message = getMessageForResponseErrorCode(errorCode)
    displayErrorMessage(mesage)
}

getMessageForResponseErrorCode(errorCode) {
   return getMappingFromErrorCodeToMessage().get(errorCode, getDefaultErrorMessage())
}

このコードには、テストする4つのメソッドがあります。可能であれば、それらすべてを応答に含めることができます。

0
User