2

私は次のコードを持っています（私は質問のために呆然としました）：

    public void HandleModeInit(int appMode){
        switch(appMode){
            Case 1:
                DoThis();
            Case 2:
                DoThat();
            Case 3:
                //no mode 3
            Case 4:
                DoSomethingElse();
            Case else:
                //do nothing
        }
    }

このメソッドを統合テスト（DoThis（）、DoThat（）、およびDoSomethingElse（）が実行していることをテストすることになります）に変えずに、どのように単体テストしますか？これらのメソッド呼び出しはHandleModeInit（）と同じクラス内のメソッドに対して行われるため、これをどのようにテストしますか？

理想的には、メソッド呼び出しは別のクラスに抽出されますが、この移動が意味をなさない場合はどうなりますか？

4

3 に答える 3

0

switch / caseステートメントを使用してappModesを切り替える代わりに、IAppModeというインターフェイスを作成できます（呼び出し元は、アプリを表すintを既に渡しているため、IAppModeを適切に実装するインスタンス化するオブジェクトを決定できると思いますモード）。

呼び出し元はIAppModeオブジェクトを渡し、メソッドはIAppModeのDoThis（）メソッドを呼び出すことができます。

次に、IAppModeを実装するダミーオブジェクトを作成し、テスト中にメソッドに挿入できます。

これにより、コードが簡単になり（デザインパターンを使用するとそれが可能になります）、テスト可能になります。

于 2009-10-05T12:54:18.803 に答える
0

私は（特にあなたがそれに気づいたことで）コードが唖然としていることに気づきましたが、この場合に呼び出されたメソッドが何をするかをテストしない場合、実際に何をテストしますか？appMode？の値

呼び出されたメソッド内で何が起こっているのかを知らずに、これをどの程度正確に攻撃するかを言うのは（不可能ではないにしても）難しいです。彼らは、モックされる可能性のあるアウトバウンドコール（外部サービス、データベースなど）を発信していますか？もしそうなら、それは前進の道かもしれません。クラスにカプセル化された動作のみが含まれている場合は、呼び出しがHandleModeInit戻ったときに確認できるプロパティ値を変更する可能性がありますか？

私は通常、コードをよりテストしやすくすることだけを目的としてコードのデザインを変更するのは好きではありませんが、1つのアプローチは、クラスのパブリックインターフェイスを内部から分離し、内部インターフェイスを次のように定義することです。インターフェイス。そうすれば、内部をあざけることができます。

于 2009-10-05T12:55:35.497 に答える
0

このメソッドに渡される内容を制御できる場合は、AppModeImplementationFactoryである引数としてappmodeを受け取るインターフェイスを渡します。このファクトリの目的は、AppModeImplementationsを作成することです。工場は次のようになります。

public class AppModeImplementationFactory: IAppModeFactory
{
   public IAppModeImplementation Create(int appMode)
   {
      // switch case goes here to create the appropriate instance
   }
}

ファクトリを渡すと、これはモックされたインスタンスである可能性があり、createメソッドが呼び出されていることを確認できます。返されたインスタンスタイプを確認する場合は、別のテストで確認する必要があります。このアプローチでは、ファクトリがappModeに基づいて必要な実装を返すため、appモードのためにロジックを実行する必要があります。

お役に立てれば

于 2009-10-06T03:06:54.160 に答える