静的は単体テストでは普遍的に「悪」であり、そうである場合、Resharperがそれを推奨するのはなぜですか？[閉まっている]

私は、C＃.NETで静的であるユニットテスト（モック/スタブ）依存関係に3つの方法しかないことを発見しました。

• ほくろ
• TypeMock
• ジャストモック

これらの2つが無料ではなく、1つがリリース1.0に達していないことを考えると、静的なものをモックするのは簡単ではありません。

それは静的な方法とそのような「悪」（ユニットテストの意味で）を作りますか？もしそうなら、なぜ再シャーパーは私に静的なもの、静的なものを作ることを望んでいますか？（再シャーパーも「悪」ではないと仮定します。）

明確化： メソッドのユニットテストを行い、そのメソッドが別のユニット/クラスで静的メソッドを呼び出す場合のシナリオについて説明しています。単体テストのほとんどの定義では、テスト対象のメソッドが他の単体/クラスの静的メソッドを呼び出すようにした場合、単体テストではなく、統合テストになります。（便利ですが、単体テストではありません。）

ここで他の答えを見ると、静的な状態を保持したり副作用を引き起こす静的メソッド（私には本当に悪い考えのように聞こえます）と、単に値を返す静的メソッドとの間に混乱があるかもしれないと思います。

状態を保持せず、副作用を引き起こさない静的メソッドは、簡単にユニットテスト可能です。実際、私はそのような方法を関数型プログラミングの「貧​​乏人」形式と考えています。メソッドにオブジェクトまたは値を渡すと、オブジェクトまたは値が返されます。これ以上何もない。このような方法が単体テストにどのような悪影響を与えるかはまったくわかりません。

静的データと静的メソッドを混同しているようです。Resharperは、正しく覚えていればprivate、クラス内のメソッドを静的にできる場合は静的にすることをお勧めします-これによりパフォーマンスが少し向上すると思います。それはしない静的な「することができ何かを」作るお勧めします！

静的メソッドに問題はなく、テストは簡単です（静的データを変更しない限り）。たとえば、静的メソッドを備えた静的クラスに適した数学ライブラリを考えてみてください。次のような（工夫された）メソッドがある場合：

public static long Square(int x)
{
    return x * x;
}

これは非常にテスト可能であり、副作用はありません。たとえば、20を渡すと400が返されることを確認するだけです。問題ありません。

ここでの本当の質問が「このコードをテストするにはどうすればいいですか？」

public class MyClass
{
   public void MethodToTest()
   {
       //... do something
       MyStaticClass.StaticMethod();
       //...more
   }
}

次に、コードをリファクタリングし、通常のように静的クラスへの呼び出しを次のように挿入します。

public class MyClass
{
   private readonly IExecutor _externalExecutor;
   public MyClass(_IExecutor executor)
   {
       _exeternalExecutor = executor;
   }

   public void MethodToTest()
   {
       //... do something
       _exetrnalExecutor.DoWork();
       //...more
   }
}

public class MyStaticClassExecutor : IExecutor
{
    public void DoWork()
    {
        MyStaticClass.StaticMethod();
    }
}

Staticsは必ずしも悪ではありませんが、偽物/モック/スタブを使用した単体テストに関しては、選択肢が制限される可能性があります。

モッキングには2つの一般的なアプローチがあります。

最初のもの（RhinoMocks、Moq、NMock2によって実装されています。このキャンプには手動のモックとスタブもあります）は、テストシームと依存性注入に依存しています。いくつかの静的コードを単体テストしており、依存関係があるとします。このように設計されたコードでよく起こることは、静的変数が独自の依存関係を作成し、依存関係の反転を反転させることです。すぐに、この方法で設計されたテスト対象のコードにモックされたインターフェイスを挿入できないことがわかります。

2番目（TypeMock、JustMock、Moleで実装されたモック）は、.NETのプロファイリングAPIに依存しています。CIL命令をインターセプトし、コードのチャンクを偽物に置き換えることができます。これにより、このキャンプ内のTypeMockおよびその他の製品は、静的、シールドクラス、プライベートメソッド-テスト可能に設計されていないもの-をモックできます。

2つの学派の間で議論が続いています。1つは、SOLIDの原則に従い、テスト容易性のために設計することです（多くの場合、静的に簡単になることを含みます）。もう1つは、TypeMockを購入しても心配しないでください。

これをチェックしてください：「静的メソッドは、テスト容易に死です」。引数の短い要約：

単体テストを行うには、コードの一部を取得し、その依存関係を再配線して、単独でテストする必要があります。これは、静的メソッドでは困難です。グローバル状態にアクセスする場合だけでなく、他の静的メソッドを呼び出すだけでも同様です。

めったに認められない単純な真実は、あるクラスが別のクラスに対するコンパイラ可視の依存関係を含む場合、そのクラスから分離してテストすることはできないということです。テストのように見え、テストのようにレポートに表示されるものを偽造できます。

ただし、テストのプロパティを定義するキーはありません。物事が間違っている場合は失敗し、正しい場合は通過します。

これは、静的呼び出し、コンストラクター呼び出し、および基本クラスまたはインターフェースから継承されていないメソッドまたはフィールドへの参照に適用されます。クラス名がコードに表示されている場合、それはコンパイラーに表示される依存関係であり、それなしでは有効にテストすることはできません。どんな小さなチャンクも、単に有効なテスト可能なユニットではありません。それをあたかもそれのように扱う試みは、テストフレームワークが「テストに合格した」と言うために使用するXMLを出力する小さなユーティリティを書くよりも意味のない結果になります。

そのため、3つのオプションがあります。

1. ユニットテストは、クラスで構成されたユニットのテストであると定義し、依存関係をハードコードします。これは、循環依存関係を回避して機能します。

2. テストを担当するクラス間にコンパイル時の依存関係を作成しないでください。これは、結果のコードスタイルが気にならない限り機能します。

3. 単体テストではなく、統合テストを行ってください。これは、統合テストという用語を使用する必要がある他の何かと競合しない限り、機能します。

それについて2つの方法はありません。ReSharperの提案とC＃のいくつかの便利な機能は、すべてのコードに対して分離されたアトミックユニットテストを作成する場合ほど頻繁には使用されません。

たとえば、静的メソッドがあり、それをスタブ化する必要がある場合、プロファイルベースの分離フレームワークを使用しない限りできません。呼び出し互換の回避策は、ラムダ表記を使用するようにメソッドの上部を変更することです。例えば：

前：

    public static DBConnection ConnectToDB( string dbName, string connectionInfo ) {
    }

後：

    public static Func<string, string, DBConnection> ConnectToDB (dbName, connectionInfo ) {
    };

2つは呼び出し互換です。発信者は変更する必要はありません。関数の本体は同じままです。

次に、Unit-Testコードで、この呼び出しを次のようにスタブできます（Databaseと呼ばれるクラスにあると仮定します）：

        Database.ConnectToDB = (dbName, connectionInfo) => { return null|whatever; }

完了したら、元の値に置き換えてください。try / finallyを介してそれを行うことができます。または、ユニットテストのクリーンアップで、各テストの後に呼び出されるクリーンアップで、次のようなコードを記述します。

    [TestCleanup]
    public void Cleanup()
    {
        typeof(Database).TypeInitializer.Invoke(null, null);
    }

これにより、クラスの静的初期化子が再度呼び出されます。

Lambda Funcsは通常の静的メソッドほどサポートが充実していないため、このアプローチには次の望ましくない副作用があります。

1. 静的メソッドが拡張メソッドであった場合、最初に非拡張メソッドに変更する必要があります。Resharperはこれを自動的に行います。
2. 静的メソッドのデータ型のいずれかがOfficeなどの埋め込み相互運用アセンブリである場合、メソッドをラップするか、タイプをラップするか、「オブジェクト」タイプに変更する必要があります。
3. Resharperの変更署名リファクタリングツールは使用できなくなりました。

しかし、静的を完全に回避し、これをインスタンスメソッドに変換するとします。メソッドが仮想であるか、インターフェイスの一部として実装されていない限り、まだモック化できません。

したがって、実際には、静的メソッドをスタブ化するための解決策を提案する人は、それらをインスタンスメソッドにすることであり、仮想またはインターフェイスの一部ではないインスタンスメソッドに対してもなります。

では、C＃に静的メソッドがあるのはなぜですか？なぜ非仮想インスタンスメソッドを許可するのですか？

これらの「機能」のいずれかを使用する場合、分離メソッドを作成することはできません。

それで、いつそれらを使いますか？

誰もスタブアウトしたくないと思われるコードに使用してください。いくつかの例：StringクラスのFormat（）メソッド、ConsoleクラスのWriteLine（）メソッド、MathクラスのCosh（）メソッド

そしてもう1つ..ほとんどの人はこれを気にしませんが、間接呼び出しのパフォーマンスについては、インスタンスメソッドを避けるもう1つの理由です。パフォーマンスが低下する場合があります。そのため、そもそも非仮想メソッドが存在します。

1. 静的メソッドは、インスタンスメソッドよりも「高速」に呼び出されるためだと考えています。（これはマイクロ最適化の匂いがするので引用符で）http://dotnetperls.com/static-methodを参照してください
2. 状態を必要としないため、どこからでも呼び出すことができ、誰かが必要とするのがそれだけである場合は、インスタンス化のオーバーヘッドを取り除きます。
3. 私がそれをモックしたいなら、それは一般的にそれがインターフェースで宣言されている習慣だと思います。
4. インターフェイスで宣言されている場合、R＃は静的にすることを提案しません。
5. 仮想と宣言されている場合、R＃は静的にすることを推奨しません。
6. 状態（フィールド）を静的に保持することは、常に慎重に検討する必要があるものです。静的状態とスレッドは、リチウムと水のように混ざります。

この提案を行うツールはR＃だけではありません。FxCop / MSコード分析も同じことを行います。

メソッドが静的である場合、一般的にはそのままテスト可能であるべきだと一般的に言っています。それはいくつかの設計上の考慮事項とおそらく今の私の指よりも多くの議論をもたらすので、辛抱強く下票とコメントを待っています...;）

久しぶりに、誰も本当に簡単な事実を述べていません。resharperがメソッドを静的にすることができると言うと、それは私にとって大きなことを意味し、彼の声が私に言うのを聞くことができます。ヘルパークラスなどで」

静的メソッドが他のmethod内部から呼び出された場合、そのような呼び出しを防止または置換することはできません。つまり、これら2つのメソッドは単一のユニットを作成します。あらゆる種類の単体テストは、両方をテストします。

そして、この静的メソッドがインターネットと対話し、データベースに接続し、GUIポップアップを表示するか、単体テストを完全な混乱に変換する場合、簡単な回避策はありません。そのような静的メソッドを呼び出すメソッドは、リファクタリングなしではテストできません。たとえ、単体テストの恩恵を受ける純粋な計算コードがたくさんあるとしてもです。

Resharperはあなたにガイダンスを提供し、セットアップされたコーディングガイドラインを適用すると信じています。Resharperを使用して、メソッドは静的である必要があることを教えてくれたとき、インスタンス変数に作用しないプライベートメソッドにバインドされます。

さて、テスト可能性に関しては、とにかくプライベートメソッドをテストするべきではないため、このシナリオは問題になりません。

パブリックな静的メソッドのテスト容易性に関しては、静的メソッドが静的状態に触れるとユニットテストが難しくなります。個人的には、これを最小限に抑え、静的メソッドを可能な限り純粋な関数として使用し、テストフィクスチャを介して制御できるメソッドに依存関係が渡されるようにします。ただし、これは設計上の決定です。