Capítulo 66. Programar con GUTs
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Kevlin Henney
¿Así que estás escribiendo pruebas unitarias? ¡Estupendo! ¿Son buenas? Tomando prestado un término de Alistair Cockburn, ¿tienes GUT? ¿Buenas pruebas unitarias? ¿O has conseguido que alguien (¿tú en el futuro?) acumule deuda técnica en su base de pruebas?
¿Qué quiero decir con bueno? Buena pregunta. Pregunta difícil. Merece una respuesta.
Empecemos por los nombres. Refleja lo que se está probando en el nombre. Sí, no quieres test1, test2, y test3 como esquema de nombres. De hecho, no quieres test en los nombres de tus pruebas: @Test ya lo hace. Dile al lector qué estás probando, no que estás probando.
Ah, no, no me refiero a ponerle el nombre del método que se está probando: dile al lector qué comportamiento, propiedad, capacidad, etc. se está probando. Si tienes un método addItemno querrás una prueba correspondiente en addItemIsOK. Es un olor a prueba muy común. Identifica los casos de comportamiento, y prueba sólo un caso por caso de prueba. Ah, y no, eso no significa addItemSuccess y addItemFailure.
Déjame preguntarte, ¿cuál es el objetivo de tu prueba? ¿Probar que "funciona"? Eso es sólo la mitad de la historia. El mayor reto del código no es determinar si "funciona", sino determinar qué significa "funciona". Tienes ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access