He estado tratando de descubrir las mejores prácticas para escribir código amigable para las pruebas, pero más específicamente las prácticas relacionadas con la construcción de objetos. En el libro azul descubrimos que debemos hacer cumplir invariantes al crear objetos para evitar la corrupción de nuestras entidades, valorar objetos, etc. teniendo en cuenta este pensamiento, Design By Contract parece ser la solución para evitar la corrupción de nuestros objetos, pero cuando si seguimos esto, podríamos terminar escribiendo código como este:

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();
   }
}

Bueno, esto se ve bien a primera vista, ¿verdad? Parece que estamos construyendo una clase segura exponiendo el contrato requerido, así que cada vez que unCar se crea el objeto, podemos estar seguros de que el objeto es "válido".

Ahora veamos este ejemplo desde un punto de vista basado en pruebas.

Quiero crear un código amigable para las pruebas, pero para poder probar de forma aislada miCar objeto Necesito crear un simulacro, un trozo o un objeto ficticio para cada dependencia solo para crear mi objeto, incluso cuando tal vez solo quiera probar un método que solo use una de estas dependencias como laStartEngine método. Siguiendo la filosofía de prueba de Misko Hevery, me gustaría escribir mi prueba especificando explícitamente que no me importa que los objetos de Puerta o Rueda simplemente pasen referencias nulas al constructor, pero como estoy buscando nulos, simplemente no puedo hacerlo @

Esto es solo un pequeño fragmento de código, pero cuando se enfrenta a una aplicación real, las pruebas de escritura se vuelven cada vez más difíciles porque tiene que resolver las dependencias de su sujeto

Misko propone que no debamos abusar de las verificaciones nulas en el código (lo que contradice el diseño por contrato) por hacerlo, escribir pruebas se convierte en un dolor, como alternativa dice que es mejor escribir más pruebas que "tener solo la ilusión" que nuestro código es seguro solo porque tenemos chequeos nulos en todas partes "

¿Qué piensas sobre esto? ¿Como lo harias? ¿Cuál debería ser la mejor práctica?