"Iteración cero" - prueba de aceptación de extremo a extremo en función de formulario de contacto simple

Question

Estaba leyendo "Creciente software orientado a objetos, guiado por pruebas" últimamente. Los autores de este libro sugirieron que siempre comenzara a desarrollar una función con una prueba de aceptación de extremo a extremo (antes de al iniciar el ciclo TDD) para no perder una pista de progreso y asegurarse de que todavía está en la misma página mientras examen de la unidad.

Ok, así que he empezado a escribir una aplicación sencilla de veeeery en python + django solo para probar este enfoque. Quiero que el usuario pueda hacer una pregunta a través de un formulario de contacto, la pregunta debe almacenarse en un DB, y se debe enviar una señal después de la finalización para notificar al remitente que enviará un mensaje de seguimiento.

La pregunta es: ¿cómo abordaría esta primera prueba de extremo a extremo en este caso? ¿Tiene usted todas las posibilidades en esta primera prueba, o tal vez estoy malinterpretando toda esta técnica?

Cualquier ejemplo sería muy bienvenido.

Answer 1

No tiene que contener todas las posibilidades en las pruebas de aceptación en absoluto; seguirá escribiendo pruebas unitarias. Por lo tanto, diría que una sola prueba: "el usuario puede completar el formulario, guardarlo y volver a cargarlo" es suficiente para comenzar. Luego puede agregar más pruebas si cree que un aspecto particular de su sistema es lo suficientemente importante como para necesitar una prueba de aceptación. No se preocupe por manejar todas las posibilidades aquí, ¡todavía escribirá toneladas de pruebas unitarias donde lo probará todo!

La forma más fácil de comenzar es hacer crecer su prueba de aceptación en paralelo con el código: así que empiece probando que el usuario puede ingresar datos, implementarlo hasta que deje de funcionar y luego agregar a la prueba la condición que tiene el usuario para cargar estos datos, etc. Llevará un tiempo implementar la infraestructura inicial para la prueba de aceptación, incluso antes de comenzar a escribir el código de producción, pero de todos modos no puede escapar de él, y existen varios beneficios de tener pruebas por adelantado.

Answer 2

Este caso de uso conduce a varios casos de prueba (cada prueba es una ruta de ejecución posible dedicada).

Cuando las pruebas de escritura se centran en un posible resultado, después de un tiempo la suite de pruebas crece. Las primeras pruebas también le dan red de seguridad como pruebas de regresión para no romper nada que ya haya implementado con éxito.

Mis primeras pruebas serían:

• camino feliz frontend-forma primera parte + capa del controlador: El usuario pasa datos correctos, el controlador toman la forma y conectarse a la consola/stdout
• camino feliz segunda parte: en lugar de conectar a la salida estándar, las cosas se almacenan en la base de datos
• camino feliz tercera parte: mail de seguimiento se envía y se recibe por el usuario
• de error de validación de manipulación (usuario llena forman de manera incorrecta, por ejemplo, no encuentra los campos obligatorios, correo electrónico- mal patrón)
• ...

completar el resto;) depende de los requisitos más detallados ...

Recuerde poner en práctica por encima de lo más simple posible. Cuando todas las pruebas estén en su lugar, refactorícese implacablemente para hacer que la "calidad interna" sea agradable.