TDD Estructura Pregunta de prueba

Question

lo tanto, decir que estoy haciendo TDD y escribo una prueba como esta:

public void testDeposit() 
{ 
    Bank b = new Bank(); 
    b.deposit(100); 
    AssertEquals(100, b.balance); 
} 

Entonces vayan y hagan el paso de la prueba, pasar a la siguiente. Digamos que hago esto por unos pocos seguidos y obtengo depósitos, retiros y amortización, todo funciona.

Luego digo que quiero escribir una prueba que pruebe a alguien creando una cuenta y haciendo una combinación de todo. ¿No es esto técnicamente una prueba de integración, no una prueba de unidad? Si lo es, ¿esto encaja en TDD, o se supone que TDD solo consiste en pruebas unitarias.

Principalmente pregunto porque, si esta prueba se rompe, lo más probable es que una de las otras pruebas se rompa, y si no lo hacen, probablemente no las haya probado con la cantidad correcta de escenarios. Entonces, ¿debería tener pruebas de integración en el mismo dominio que las pruebas unitarias cuando se trata de TDD, o deberían estar escritas en otra clase/archivo en otro lugar y ejecutarse por separado?

Answer 1

Creo que las pruebas de alto nivel sin duda pueden tener un lugar como parte de un flujo de trabajo TDD. Por ejemplo, probar "afuera adentro" puede ser una manera muy efectiva de definir nuevas características. Comience con alguna prueba de aceptación del nivel de interfaz de usuario para la nueva característica, escriba pruebas de integración para los componentes que deberán existir para proporcionar esa característica, y escriba pruebas de unidades para impulsar la implementación de cada componente.

Creo que debe mantener clara la distinción entre sus tipos de pruebas y no mezclarlas, pero puede tener sentido incluirlas como parte de su proceso TDD.

Answer 2

La línea entre las pruebas de integración y las pruebas unitarias puede ser un poco borrosa; vale la pena, mientras hace TDD, probar "hasta" un nivel de integración, solo para obtener la confirmación de la funcionalidad, pero sin duda es excesivo durante TDD para poner en marcha pruebas de integración "integrales" (tenga en cuenta las cotizaciones completas allí).

Básicamente, hay un aspecto importante de la "llamada de juicio" en curso; su experiencia debe ser una buena guía en cuanto al nivel apropiado para dejar de agregar pruebas durante el modo TDD.