現在のプロジェクトのユニットテストをいくつか書き始めました。私は実際にそれを経験していません。最初に完全に「取得」したいので、現在IoCフレームワークもモックライブラリも使用していません。

ユニットテストでオブジェクトのコンストラクターにnull引数を提供することに何か問題があるのではないかと思っていました。サンプルコードを提供します。

public class CarRadio
{...}


public class Motor
{
    public void SetSpeed(float speed){...}
}


public class Car
{
    public Car(CarRadio carRadio, Motor motor){...}
}


public class SpeedLimit
{
    public bool IsViolatedBy(Car car){...}
}

さらに別のCar Code Example（TM）は、質問にとって重要な部分のみに縮小されました。次のようなテストを作成しました。

public class SpeedLimitTest
{
    public void TestSpeedLimit()
    {
        Motor motor = new Motor();
        motor.SetSpeed(10f);
        Car car = new Car(null, motor);

        SpeedLimit speedLimit = new SpeedLimit();
        Assert.IsTrue(speedLimit.IsViolatedBy(car));
    }
}

テストは正常に実行されます。SpeedLimit必要CarとしMotor、そのことを行うために。それはまったく興味がないCarRadioので、そのためにヌルを提供しました。

完全に構築されずに正しい機能を提供するオブジェクトが、SRPの違反またはコードの匂いであるかどうか疑問に思っています。私はこのしつこい感じを持っていますが、speedLimit.IsViolatedBy(motor)どちらかと言えば正しくありません-モーターではなく車が速度制限に違反しています。全体の意図は全体の一部のみをテストすることであるため、単体テストと作業コードでは異なる視点が必要なのかもしれません。

単体テストでnullを使用してオブジェクトを構築すると、コードのにおいがしますか？

上記の例の場合、がなくてもa Carが存在することは理にかなっていますCarRadio。その場合、nullを渡すことが許容される場合があるだけでなくCarRadio、必須であると言います。テストでは、Carクラスの実装が堅牢であり、存在しない場合にNULLポインター例外をスローしないことを確認する必要がありますCarRadio。

ただし、別の例を見てみましょう-を考えてみましょうSteeringWheel。aにa Carが必要であると仮定しましょうSteeringWheel、しかし速度テストはそれを本当に気にしません。この場合、null SteeringWheelを渡すCarことはありません。これは、クラスを移動するように設計されていない場所にプッシュするためです。この場合、DefaultSteeringWheel（メタファーを続けるために）ある種の直線を作成するほうがよいでしょう。

単体テストでnullを使用してオブジェクトを構築すると、コードのにおいがしますか？

はい。コードの匂いの C2定義に注意してください：「CodeSmellは、確実性ではなく、何かが間違っているかもしれないというヒントです。」

テストは正常に実行されます。SpeedLimitには、モーターを搭載した車が必要です。CarRadioにはまったく興味がないので、そのためにnullを提供しました。

コンストラクターに渡される引数にspeedLimit.IsViolatedBy(car)依存しないことを実証しようとしている場合CarRadio、おそらく、テストが呼び出された場合にテストに失敗するテストダブルを導入することで、その制約を明示的にすることは将来のメンテナーにより明確になるでしょう。

おそらくそうであるようにCarRadio、この場合は使用されないことがわかっているものを作成する作業を自分で保存しようとしている場合は、

• これはカプセル化の違反です（CarRadio使用されていないという事実をテストに漏らしています）
• をCar指定せずに作成したいケースを少なくとも1つ発見しましたCarRadio

コードは、次のようなコンストラクタが必要であることを伝えようとしていると強く疑っています

public Car(IMotor motor) {...}

そして、そのコンストラクタは、何もないという事実をどうするかを決めることができますCarRadio

public Car(IMotor motor) {
    this(null, motor);
}

または

public Car(IMotor motor) {
    this( new ICarRadio() {...} , motor);
}

または

public Car(IMotor motor) {
    this( new DefaultRadio(), motor);
}

等

SpeedLimitのテスト中にnullを他の何かに渡す場合です。テストが「SpeedLimitTest」と呼ばれ、AssertがSpeedLimitのメソッドをチェックしていることがわかります。

これは2番目の興味深い匂いです。SpeedLimitをテストするためには、おそらくSpeedLimitのチェックで気になるのは速度だけですが、ラジオの周りに車全体を構築する必要があります。

これは、車全体を必要とするのではなく、車が実装SpeedLimit.isViolatedByするロールインターフェイスを受け入れる必要があるヒントかもしれません。

interface IHaveSpeed {
    float speed();
}

class Car implements IHaveSpeed {...}

IHaveSpeed本当にお粗末な名前です。ドメイン言語が改善されることを願っています。

そのインターフェイスSpeedLimitが適切に配置されていれば、テストはもっと簡単になります

public void TestSpeedLimit()
{
    IHaveSpeed somethingTravelingQuickly = new IHaveSpeed {
        float speed() { return 10f; }
    }

    SpeedLimit speedLimit = new SpeedLimit();
    Assert.IsTrue(speedLimit.IsViolatedBy(somethingTravelingQuickly));
}

単体テストでnullを使用してオブジェクトを構築すると、コードのにおいがしますか？

いや

どういたしまして。それどころか、NULL引数として使用可能な値がある場合（一部の言語では、nullポインターの受け渡しを禁止する構成体がある場合があります）、テストする必要があります。

別の質問は、合格するとどうなるかですNULL。しかし、それはまさに単体テストの目的です。可能な入力ごとに定義された結果が確実に発生するようにします。そしてNULL あるあなたが定義した結果を持っていなければならないし、そのためのテストを持っている必要がありますので、潜在的な入力。

あなたの車がラジオなしで構築可能であることになっているのであれば、そのためのテストを書く必要があります。そうではなく、例外をスローすることになっている場合は、そのためのテストを作成する必要があります。

いずれにせよ、はいのテストを書く必要がありますNULL。省略した場合、コードの匂いがします。それは、魔法のようにバグがないと仮定したコードの未テストのブランチがあることを意味します。

テスト対象のコードが改善される可能性があるという他の回答にも同意することに注意してください。それにもかかわらず、改善されたコードがポインターであるパラメーターを持っている場合、改善されたコードでNULLさえ渡すことは良いテストです。NULLモーターとして合格すると何が起こるかをテストで確認したいと思います。それはコードの匂いではなく、コードの匂いの反対です。テスト中です。

私は個人的にヌルを注入することをためらいます。実際、依存関係をコンストラクターに注入するときはいつでも、最初に行うことの1つは、それらの注入がヌルの場合、ArgumentNullExceptionを発生させることです。そうすれば、クラス内でそれらを安全に使用でき、何十ものnullチェックが広まることはありません。これは非常に一般的なパターンです。コンストラクターで設定された依存関係を後でnull（またはその他）に設定できないようにするために、読み取り専用の使用に注意してください。

class Car
{
   private readonly ICarRadio _carRadio;
   private readonly IMotor _motor;

   public Car(ICarRadio carRadio, IMotor motor)
   {
      if (carRadio == null)
         throw new ArgumentNullException(nameof(carRadio));

      if (motor == null)
         throw new ArgumentNullException(nameof(motor));

      _carRadio = carRadio;
      _motor = motor;
   }
}

上記を使用すると、nullチェックが期待どおりに機能することを確認するために、1つまたは2つのユニットテストを実行して、nullを挿入できます。

ただし、次の2つのことを行うと、これは問題になりません。

1. クラスの代わりにインターフェイスにプログラムします。
2. モックフレームワーク（C＃のMoqなど）を使用して、nullの代わりにモックされた依存関係を注入します。

したがって、あなたの例では：

interface ICarRadio
{
   bool Tune(float frequency);
}

interface Motor
{
   bool SetSpeed(float speed);
}

...
var car = new Car(new Moq<ICarRadio>().Object, new Moq<IMotor>().Object);

Moqの使用に関する詳細については、こちらをご覧ください。

もちろん、最初にモックせずに理解したい場合でも、インターフェイスを使用している限り、それを行うことができます。次のようにダミーのCarRadioとMotorを作成し、代わりにそれらを挿入します。

class DummyCarRadio : ICarRadio
{
   ...
}
class DummyMotor : IMotor
{
   ...
}

...
var car = new Car(new DummyCarRadio(), new DummyMotor())

大丈夫というだけでなく、レガシーコードをテストハーネスに組み込むための、よく知られた依存関係を破る手法です。（Michael Feathersによる「レガシーコードの効果的な使用」を参照してください。）

匂いがする？まあ...

テストは香りがしません。テストはその仕事をしています。「このオブジェクトはnullでも、テスト対象のコードは引き続き正常に動作します」と宣言しています。

臭いは実装にあります。コンストラクター引数を宣言することにより、「このクラスは適切に機能するためにこのことを必要とします」と宣言しています。明らかに、それは真実ではありません。間違っていることは少し臭いです。

最初の原則に戻りましょう。

単体テストは、単一のクラスのいくつかの側面をテストします。

ただし、他のクラスをパラメーターとして取るコンストラクターまたはメソッドがあります。これらの処理方法はケースごとに異なりますが、目的に正接しているため、セットアップは最小限にする必要があります。NULLパラメーターを渡すことが完全に有効であるシナリオがあります（ラジオのない車など）。

ここでは、レースラインをテストして（車のテーマを継続するために）単にテストしていると仮定していますが、他のパラメーターにNULLを渡して、防御コードと例外処理メカニズムが機能していることを確認することもできます必須。

ここまでは順調ですね。ただし、NULL が有効な値ではない場合はどうなりますか。さて、ここであなたはモック、スタブ、ダミー、偽物の暗い世界にいます。

これらすべてを実行するのが少し難しいと思われる場合、実際にはCarコンストラクターにNULLを渡すことで既にダミーを使用しています。これは、潜在的に使用されない値だからです。

すぐに明らかになるのは、多くのNULL処理を使用してコードをショットガンする可能性があるということです。クラスパラメータをインターフェイスに置き換えると、モックやDIなどの処理も​​簡単になります。

あなたのデザインを見てみると、Carがのセットで構成されていることをお勧めしFeaturesます。フィーチャー多分CarRadio、またはEntertainmentSystemそのようなものから構成することができるCarRadio、DvdPlayerなど

したがって、少なくとも、Carのセットでを構築する必要がありますFeatures。EntertainmentSystemそして、CarRadioの（Java（登録商標）、C＃等）インターフェースの実装となりpublic [I|i]nterface Feature、これは複合デザインパターンのインスタンスであろう。

そのため、常にCarwith Featuresを構築し、単体テストはCarwithoutをインスタンス化しませんFeatures。BasicTestCarFeatureSet最も基本的なテストに必要な最小限の機能セットを持つモックを検討することもできます。

いくつかの考え。

ジョン