Проектирование по контракту, написание удобного для тестирования-кода, создание объектов и внедрение зависимостей, объединяющие лучшие практики

Я пытался выяснить лучшие практики написания кода,-дружественного к тестированию, но более конкретно практики, связанные с созданием объектов. В синей книге мы обнаружили, что мы должны применять инварианты при создании объектов, чтобы избежать повреждения наших сущностей, объектов-значений и т. Д. Имея в виду эту мысль, проектирование по контракту кажется решением, позволяющим избежать повреждения наших объектов, но когда мы следуем этому, мы могли бы в конечном итоге написать такой код:

class Car
{
   //Constructor
   public Car(Door door, Engine engine, Wheel wheel)
   {
      Contract.Requires(door).IsNotNull("Door is required");
      Contract.Requires(engine).IsNotNull("Engine is required");
      Contract.Requires(wheel).IsNotNull("Wheel is required");
     ....
   }
  ...
   public void StartEngine()
   {
      this.engine.Start();
   }
}

Ну, на первый взгляд это выглядит хорошо, верно? Кажется, мы создаем безопасный класс, раскрывающий требуемый контракт, поэтому каждый раз, когда создается объект Car, мы можем точно знать, что объект «действителен».

Теперь давайте посмотрим на этот пример с-проверочной точки зрения.

Я хочу создать дружественный к тесту -код, но для того, чтобы иметь возможность тестировать мой Carобъект изолированно, мне нужно создать либо макет заглушки, либо фиктивный объект для каждой зависимости только для того, чтобы создать мой объект, даже когда, возможно, я просто хочу протестировать метод, который использует только одну из этих зависимостей, например метод StartEngine. Следуя Миско Хевери, философии тестирования, я хотел бы написать свой тест, явно указав, что меня не волнуют объекты Door или Wheel, просто передающие нулевую ссылку конструктору, но поскольку я проверяю наличие нулей,Я просто не могу этого сделать

Это всего лишь небольшой фрагмент кода, но когда вы сталкиваетесь с реальным приложением, написание тестов становится все сложнее и сложнее, потому что вам нужно разрешать зависимости для вашего предмета

Миско предлагает, чтобы мы не злоупотребление нулевыми-проверками в коде(, что противоречит принципу проектирования по контракту), из-за этого написание тестов становится мучением, в качестве альтернативы, по его словам, лучше написать больше тестов, чем «иметь только иллюзию, что наш код безопасен только потому, что у нас везде нулевые-проверки"

Что вы думаете по этому поводу? Как бы вы это сделали? Какой должна быть лучшая практика?