Las especificaciones de escritura (aserciones o hipótesis de prueba) generalmente se omiten en los cursos de TDD porque hay poca programación.
Sin embargo, son muy importantes.
Determinan cómo y qué pruebas se escribirán, y también determinan qué tan fácil será arreglar el desglose. Casi no requieren tiempo para la implementación. Son los primeros que conectan al usuario de la historia y el código y los primeros que muestran la falla del código de prueba. También son lo que además nos protege de errores en el código de la prueba en sí.
¿Cómo podríamos mejorar nuestras declaraciones?
Primero, las
especificaciones deben estar relacionadas con la historia del usuario en términos . Si el usuario de la historia usa el término "iniciar sesión", aserción no puede cambiar este término para autenticar / autorizar / validar. Si la historia no está bien escrita, cámbiela.
En segundo lugar, la
especificación debe contener explícitamente el nombre del componente que describen. Esto denota el área de prueba y señala un error, si de repente el águila pescadora a menudo incluye algunos componentes inesperados.
El script válido se combina bien con el principio de responsabilidad única, por lo que el nombre del componente debe coincidir con la descripción de la prueba. Si hay muchos escenarios válidos, entonces probablemente el componente tiene demasiada responsabilidad.
Además, un escenario, como regla, describe un evento ui o algún tipo de patrón. Los buenos candidatos para el nombre del componente pueden contener el nombre del patrón: Validador, Estrategia, Constructor, Transformador, Controlador, etc. O nombre del evento: Remitente, Inicio de sesión, ReadonlyOrderView, etc. Es decir dependiendo del nombre del componente, se deben definir los valores de entrada y salida de la función principal de la clase. Nombres incorrectos: demasiado abstracto (Servicio, Componente, Ayudante, Utilidad) y doble (ValidatorAndRenderer).
En tercer lugar, las
especificaciones deben indicar explícitamente las condiciones .
Malo:
@Test public void testValidatePassword(){}
Mejor:
@Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}
No tenemos que llamar a esta función desde otro lugar, por lo que los nombres extra largos son válidos. Si el número de condiciones en la prueba no se ajusta a la línea, entonces quizás debería cambiar la estructura del componente.
Para las pruebas de JavaScript lo mismo, pero puede poner condiciones allí, resulta más conveniente.
describe('login UI component', () => { describe('when username provided', () => { describe('when valid password', () => { it('should log user in', () => { ... }); }); }); });
Las condiciones explícitas son más fáciles de leer y las que
faltan .
Además, si la condición no coincide con el código de prueba escrito, entonces el código es fácil de corregir.
Una buena descripción es, en general, un reemplazo de documentación y comentarios de código. Es abstracto, no depende del marco y el compilador, y debe tratarse con la misma seriedad que los dos últimos.
Las condiciones en sí mismas deben ser consistentes en el código para facilitar la lectura, por ejemplo, DADO, CUANDO, ENTONCES, etc.
Cuarto, las
especificaciones deberían simplificarse . Es útil escribirlos en orden inverso:
Errores primero, nulos primero, camino feliz al final. Entonces no hay deseo de terminar la prueba después de un caso de usuario válido. Para componentes de la interfaz de usuario: representación, eventos. Para componentes con estado, todos los estados son consistentes.
Por lo tanto, la estructura de una buena especificación legible se ve así: 5-10 errónea, un script válido (o varias variaciones de un script)
Cuando se escribe una especificación, es una buena práctica escribirla en forma de texto, y luego dejar que su colega la lea para mayor claridad y condiciones faltantes. Entonces, de hecho, ya puede comenzar a escribir la implementación. Muy a menudo, de esta forma, la tarea se aliena, es decir bueno, cuando alguien más escribe la implementación de la prueba.
En quinto lugar, la
implementación de la prueba debe corresponder a lo que está escrito en describe .
Es una buena práctica dividir en organizar-actuar-afirmar para encontrar fácilmente una coincidencia para una u otra parte de la implementación. El texto de aserciones y excepciones, si está presente, también debe estar correlacionado con las descripciones de las pruebas, por regla general, simplemente podemos duplicarlas.
No es necesario decir que al agregar condiciones o aserciones a la prueba, también debe actualizar las descripciones de la prueba.
Entonces, la secuencia de escribir la especificación puede ser la siguiente.
- leer la historia del usuario
- componente de nombre y script válido
- formular condiciones para un escenario válido
- Complemente la especificación con guiones erróneos colocándolos encima
- deja que el vecino lea y corrija lo que falta
- Implemente pruebas y componentes uno por uno utilizando un bucle refactor rojo-verde.