Las pruebas unitarias no solo facilitan el diseño, sino que ese es uno de sus principales beneficios.
Escribir prueba primero elimina la modularidad y la estructura de código limpia.
Cuando escriba su prueba de código primero, encontrará que cualquier "condición" de una unidad de código dada se expulsa naturalmente a las dependencias (generalmente a través de simulaciones o apéndices) cuando las asume en su código.
"Dada la condición x, espere comportamiento y", a menudo se convertirá en un trozo para suministrar x
(que es un escenario en el que la prueba necesita verificar el comportamiento del componente actual) y y
se convertirá en un simulacro, una llamada a la que se verificará en el final de la prueba (a menos que sea un "debería regresar y
", en cuyo caso la prueba solo verificará el valor de retorno explícitamente).
Luego, una vez que esta unidad se comporta como se especifica, pasa a escribir las dependencias (para x
y y
) que ha descubierto.
Esto hace que escribir código limpio y modular sea un proceso muy fácil y natural, donde de lo contrario a menudo es fácil difuminar las responsabilidades y unir los comportamientos sin darse cuenta.
Escribir pruebas más adelante le dirá cuándo su código está mal estructurado.
Cuando escribir pruebas para un fragmento de código se vuelve difícil porque hay demasiadas cosas para tropezar o burlarse, o porque las cosas están demasiado unidas, sabes que tienes mejoras que hacer en tu código.
Cuando "cambiar las pruebas" se convierte en una carga porque hay tantos comportamientos en una sola unidad, sabe que tiene que hacer mejoras en su código (o simplemente en su enfoque para escribir pruebas, pero este no es el caso en mi experiencia) .
Cuando sus escenarios se vuelven demasiado complicados ("if x
and y
and z
then ...") porque necesita abstraer más, sabe que tiene que hacer mejoras en su código.
Cuando terminas con las mismas pruebas en dos dispositivos diferentes debido a la duplicación y la redundancia, sabes que tienes mejoras que hacer en tu código.
Aquí hay una excelente charla de Michael Feathers que demuestra la estrecha relación entre la capacidad de prueba y el diseño en el código (originalmente publicado por displayName en los comentarios). La charla también aborda algunas quejas comunes y conceptos erróneos sobre el buen diseño y la capacidad de prueba en general.