2

現在、私はいくつかのプロジェクトの単体テストを行っていますが、開発者が次のようなものを使用した場所を除いて、すべて問題ありません:

#if USING_EMULATOR
{ do nothing }
#else
{ do a lot of things }
#endif

また

#if USING_EMULATOR
  return;
#endif
{ do a lot of things }

下のコードUSING_EMULATORがデバッグ目的で行われた場所だと思います。また、時々#if DEBUG登場します。デバッグ目的でのみ実行しようとしているコードの実際の部分を確認するにはどうすればよいですか? #undef USING_EMULATOR役に立ちません。私はプリプロセッサ定数を明確に理解していません.C＃では、定義済み/未定義のみを設定することさえできないので、間違っているのでしょうか？

4

3 に答える 3

5

リファクタリングの自由度があると仮定すると、これらのディレクティブをプライベートまたは保護されたプロパティに抽出し、テストで値を変更するためのフックを自分自身に与えることができます。

のようなものへの依存関係を抽出することもできます。その依存関係IRuntimeConfigurationをテストのスタブに置き換えることができます。

例えば：

public class ClassIAmTesting
{
    private readonly IRuntimeConfiguration _runtimeConfig;
    public ClassIAmTesting(IRuntimeConfiguration runtimeConfig)
    {
        _runtimeConfig = runtimeConfig;
    }

    public void MethodIWantToTest()
    {
        if(_runtimeConfig.IsDebug)
            return;

        // …
    }
}

public interface IRuntimeConfiguration
{
    bool IsDebug { get; }
    bool IsUsingEmulator { get; }
}

public class RuntimeConfiguration : IRuntimeConfiguration
{
    public bool IsDebug
    {
        get
        {
            return
#if DEBUG
                true;
#else
                false;
#endif
        }
    }

    // repeat for IsUsingEmulator
}

このように、実行するコードの「選択」は、プリプロセッサ ディレクティブに基づくのではなく、通常のboolプロパティの値に基づきます。IRuntimeConfiguration常に を返す別の実装に置き換えると、プリプロセッサの値が実際に設定されている場合でも、ないかのfalseようにコードを実行できます。DEBUGUSING_EMULATOR

于 2012-09-25T13:31:52.257 に答える
3

USING_EMULATORプロジェクトのビルド設定の条件付きコンパイル シンボルから削除します。

さまざまな条件付きコンパイル シンボルのセットを使用して、さまざまなビルド構成を作成することもできます。たとえば、Debug config は DEBUG を定義しますが、Release は定義しません。これは、実際のコードを実行する場合は、デバッグ ビルドではなくリリース ビルドを実行する必要があることも意味します。

于 2012-09-25T13:28:02.553 に答える
1

トリッキーなもの。の両側を単体テストする場合は#if、2 つのビルドを実行する必要があります。1 つはUSING_EMULATOR定義済みで、もう 1 つは定義なしです。

これは、C# では、コードが条件付きでコンパイルされると、コードがまったく存在しないことと同じになるためです。したがって、(あなたの例では)が定義されている場合、定義されていない場合とは異なる非同等のプログラムUSING_EMULATORにコンパイルされます。USING_EMULATOR

したがって、両方の「プログラム」を単体テストする場合は、テスト対象のソフトウェアの 2 つの異なるビルドを単体テストする必要があります。

シナリオによっては、ソフトウェアの一部を再構築して、さまざまな環境で必要に応じて動作を変更するために、必要に応じてさまざまなコンポーネントをオーバーライドできるようにすることが適切な場合があります。このようにして、オーバーライドされた部分の両方の実装がすべてのビルドに存在し、適切に構造化された単体テストを使用してテストできます。

于 2012-09-25T13:30:35.060 に答える