BDD/TDD burlarse de los datos de la manera engañosa

Question

Así que un compañero de trabajo y yo estamos en un debate bastante acalorado. Estamos comenzando un nuevo proyecto y estamos intentando usar BDD. Los dos somos principiantes y no comprendemos completamente qué prácticas deberían usarse. Hemos escrito algunas especificaciones y ahora estamos implementando el código. Las cosas se vuelven bastante complicadas ya que hay mucha interacción con la base de datos. Estamos estancados en cómo debemos burlarnos de nuestros datos. El método que estábamos siguiendo nos obligaría a burlarnos de nuestros métodos en lugar de nuestros datos. Es más fácil si te muestro en el código ...

public static void AssignLeadToDistributor(int leadId, int distributorId) 
{ 
    Lead lead = GetById(leadId); 
    lead.DistributorId = distributorId; 
    Save(lead); 
} 

Básicamente, tendríamos que anular GetById() y Save() para devolver los datos simulados para poner a prueba esta. Se parece que tiene más sentido hacerlo así:

public static void AssignLeadToDistributor(Lead lead, Distributor distributor) 
{ 
    lead.DistributorId = distirbutor.Id; 
} 

entonces podríamos simplemente burlarse de nuestros objetos.

Claramente, el segundo método lo hace más fácil de probar. Sin embargo, el argumento es que no queremos tener que buscar un nuevo objeto principal y distribuidor en nuestro código front-end, porque sería más fácil pasar los identificadores de nuestros objetos. Reducir el código real en nuestra parte delantera.

Afortunadamente lo expliqué lo suficiente.

¿Qué piensan? ¿Qué forma tiene más sentido?

Answer 1

Lo que hacemos en nuestras especificaciones de BDD (historias ejecutables), es no burlar el DB en absoluto, sino usar un DB en memoria (SQLite en nuestro caso).

Además, inicializamos el contenedor antes de ejecutar cualquier escenario. Esto se debe a que nos gustaría que nuestras especificaciones de BDD imiten el mundo real en la medida de lo posible, al tiempo que siguen teniendo la velocidad de las pruebas de unidades ordinarias.

Al definir nuestras especificaciones BDD de esta manera, hemos encontrado la necesidad de disminuir las pruebas unitarias y de integración, y hemos aumentado tanto la productividad como la comprensión (aunque muy subjetiva ya que no se pueden medir realmente).

Answer 2

Creo que el problema más grande que tienes es que estás usando funciones públicas estáticas (lo cual generalmente es malo en los lenguajes OO).

me gustaría sugerir mover esta función para el objeto principal, algo así como

public AssignDistributor(int distributorId) { 
    this.DistributorId = distributorId; 
    this.Save(); 
} 

Más fácil de probar, y más código OO-como =)

Answer 3

me gusta el segundo método mejor, para el razón por la que declaró: puede burlarse de los parámetros fácilmente para probar. ¿Estás usando un marco de inyección de dependencia? Si no, entonces te recomiendo que programes tus métodos usando el principio de Dependency Injection de todos modos para un código más modular y fácil de probar.

Y estoy de acuerdo con Samuel en que debe evitar el uso de métodos estáticos siempre que sea posible, o le resultará muy difícil probarlos.