Iniciar un proyecto TDD desde cero

Question

He leído muchas preguntas y respuestas sobre TDD y pruebas unitarias en SO, pero no he encontrado nada que responda a eso: ¿por dónde empiezo?

Yo y el equipo ya hemos hecho un par de proyectos en los que hemos adoptado el uso de pruebas unitarias, para nuestro código ... pero codifica primero y luego prueba unitaria. En algún punto del proceso de desarrollo, se hizo bastante natural escribir primero la prueba y luego el código, lo que nos llevó a un estilo más TDD.

Ahora nos gustaría dar el siguiente paso y tratar de comenzar un nuevo proyecto con TDD desde el principio. Aquí está el problema ... ¿por dónde empezar? ¿Cuál es la primera prueba que escribiría cuando no tenga ningún código?

Digamos, solo para tener un contexto en el que pensar, que tengo que desarrollar una aplicación de Internet, centrada en el documento, con un poco de flujo de trabajo y ... algo más. Pero comencemos desde el principio: primero, quiero crear una página simple que liste todo el documento (metadatos) almacenado en una tabla en un DB (bastante simple, ¿eh?). ¿Cuál es la primera prueba que escribiría? Digamos que estoy usando Hibernate para acceder al db ... ¿probaría el método ipotético getAllDocuments()? Pero, ¿debería usar un objeto simulado para sustituir a Hibernate? Entonces, ¿qué estoy probando?

Estoy un poco confundido aquí ... además el getAlDocuments() probablemente nunca será un método de producción ... toda la colección de documentos será ordenada y filtrada por algo ... ¿tiene sentido? Cualquier sugerencia será apreciada

Editado:

Después de leer sus respuestas (y el hilo similar en http://programmers.stackexchange.com) Vengo con una mejor visión de TDD, pero todavía tengo un dubt.

Siempre pensé que TDD se trata de hacer la prueba de unidad primero ... nunca pensé en la prueba de extremo a extremo. Pero déjame preguntarte: TDD dice que tienes que escribir una prueba y ver un error de compilación; luego creas clase y método y obtienes una falla de prueba; luego implementa el método y pasa la prueba. No puede escribir código hasta que falle una prueba; no puede escribir otra prueba hasta que pase todo el examen. ¿Estoy aquí?

¿Cómo puedo hacer una prueba de extremo a extremo como mi primera prueba? Debería escribir todo el código, en toda la capa, para dejar pasar esa prueba. Pero luego tendré un montón de clases y métodos, todos probados por mi prueba integral (¿no debería llamarlo prueba de integración?). Esto significa que ya no necesitaré la prueba de unidad, porque ya tengo una prueba que cubre mi código. Y no puedo escribir una prueba que ya haya pasado, está en contra de la práctica de TDD.

ayuda a entender este nuevo paso por delante favor

Answer 1

TDD no es de las pruebas unitarias - TDD se trata de la conducción de su desarrollo y la arquitectura con pruebas - con cualquier tipo de pruebas automatizadas que necesita. ¿Ves el punto?

Está iniciando un nuevo proyecto y probablemente tenga un conjunto de características. Debe tener algunos criterios de aceptación para las características que va a implementar. Estos criterios pueden definir sus pruebas de nivel superior. Comencemos con una prueba de extremo a extremo (esto puede ser bastante difícil a veces porque involucra una IU que aún no existe) o una prueba de integración para estos criterios de aceptación. Una vez que tenga la prueba que está fallando, continuará implementando las características relacionadas con la prueba grande, pero cada una de estas características será impulsada nuevamente con una prueba de integración o de unidad. La característica se completa si pasan todas las pruebas de nivel superior.

Si omite pruebas grandes (extremo a extremo, integración) desarrollará un conjunto de unidades bien probadas que o no funcionarán cuando estén integradas juntas o su arquitectura no será muy buena debido al alcance local definido por unidad pruebas. La integración y las pruebas de extremo a extremo le dan un alcance global.

Esto se describe con un gran ejemplo (Java) en el libro Growing Object-Oriented Software Guided by Tests.

Answer 2

Comience de manera simple, agregará las características gradualmente más adelante. Comience desde un diseño rápido: qué clases, qué responsabilidades, qué relaciones. Puede usar CRC cards. No dedique demasiado tiempo a ese diseño, ya que podrá mejorarlo más adelante mediante Refactorización. Elija la clase más simple para comenzar a implementar una capacidad simple del sistema. Por ejemplo, primero puedes crear una página vacía.

¿Comenzar con una clase? ¿Qué harán sus objetos? ¿Cómo puedes verificar que esto se hace correctamente? Esta es la primera prueba.

También podría comenzar sin la base de datos y almacenar sus documentos en un archivo plano. Volverás a configurar una base de datos más tarde. Luego puede comenzar con la función getAllDocuments().

Answer 3

Normalmente empiezo de arriba abajo. En su caso, comenzaría escribiendo la lógica del controlador de su nueva página. Por controlador me refiero a la capa de código justo debajo de la interfaz de usuario, burlándote de todo lo que está debajo. Luego, escribe la capa de servicio (si tienes una), burlándose de la capa de datos. Finalmente, pruebe la capa de datos con simulaciones de las clases subyacentes (podría ser ISession en su caso). Finalmente, escribiría una única prueba de integración de cada uno de los métodos de la capa de datos y construiría la página (html).

Answer 4

Dado que está intentando conducir el desarrollo según las pruebas, la manera de comenzar es comenzar con su primera característica. Por ejemplo, supongamos que tiene una función para cargar documentos. Su primera prueba puede ser:

public class DocumentManagementTest { 
    @Test public void allowsDocumentUploads() { 
    DocumentManagement dm = new DocumentManagement(); 
    Reader mockReader = new MockDocumentReader(); 

    Document result = dm.createDocument("Document name", mockReader); 

    assertEquals("Document name", result.getName()); 
    assertEquals(0, result.getTags().size()); 
    assertTrue(mockReader.fileWasRead); 
    } 
} 

Sin duda, burlarse de la base de datos, para empezar, la configuración de base de datos y el desmontaje es caro y frágil. Sin embargo, recuerde que para dar pasos muy pequeños, la prueba que mostré anteriormente probablemente evolucionó en algunas iteraciones. pruebas de seguimiento que impulsan más del diseño pueden ser:

@Test public void allowsDocumentRenames() { ... } 
@Test public void allowsAddingTagsToExistingDocuments() { ... } 
@Test public void showsErrorWhenAddingDocumentThatAlreadyExists() { ... } 

Una vez que se ha construido a cabo una característica como createDocument puede crear un controlador a su alrededor.

public void doPost(HttpServletRequest req, HttpServletResponse resp) { 
    String name = req.getParameter("doc_name"); 
    Document d = docMgmt.createDocument(name, req.getInputStream()); 
    // Hand the newly created document to the view engine. 
} 

yo no preocuparse demasiado acerca de cómo escribir pruebas para el controlador, ya que bastante bajo riesgo desde el punto de vista complejidad (si el controlador se pone demasiado código, entonces puede ser un olor que el código del controlador pertenece otra clase, posiblemente su clase DocumentManagement).

Desarrollando la funcionalidad una característica a la vez y siguiendo los principios SÓLIDOS, crecerá lentamente un sistema con gran cobertura de prueba y muy buenas propiedades OO.

¡Salud!

Brandon