Es difícil y poco realista mantener grandes datos simulados. Es aún más difícil cuando la estructura de la base de datos sufre cambios.
Falso.
Las pruebas unitarias no requieren datos simulados "grandes". Requiere suficientes datos simulados para probar los escenarios y nada más.
Además, los programadores verdaderamente perezosos piden a los expertos en la materia que creen hojas de cálculo simples de los diversos casos de prueba. Solo una simple hoja de cálculo.
Luego, el programador perezoso escribe un script simple para transformar las filas de la hoja de cálculo en casos de prueba unitaria. Es bastante simple, de verdad.
Cuando el producto evoluciona, las hojas de cálculo de los casos de prueba se actualizan y se generan nuevas pruebas unitarias. Hazlo todo el tiempo. Realmente funciona.
Incluso con MVVM y la capacidad de probar la GUI, se necesita mucho código para reproducir el escenario de la GUI.
¿Qué? "Reproducir"?
El objetivo de TDD es diseñar cosas para Testability (Test Drive Development). Si la GUI es tan compleja, debe ser rediseñada para que sea más simple y comprobable. Más simple también significa más rápido, más fácil de mantener y más flexible. Pero sobre todo más simple significará más comprobable.
Tengo experiencia de que TDD funciona bien si lo limita a una lógica comercial simple. Sin embargo, la lógica empresarial compleja es difícil de probar ya que el número de combinación de prueba (espacio de prueba) es muy grande.
Eso puede ser verdad.
Sin embargo, pedirles a los expertos en la materia que proporcionen los casos de prueba básicos en una forma simple (como una hoja de cálculo) realmente ayuda.
Las hojas de cálculo pueden volverse bastante grandes. Pero está bien, ya que usé un simple script de Python para convertir las hojas de cálculo en casos de prueba.
Y. Tuve que escribir algunos casos de prueba manualmente porque las hojas de cálculo estaban incompletas.
Sin embargo. Cuando los usuarios informaron "errores", simplemente pregunté qué caso de prueba en la hoja de cálculo era incorrecto.
En ese momento, los expertos en la materia corregirían la hoja de cálculo o agregarían ejemplos para explicar lo que se suponía que sucedería. Los informes de errores pueden, en muchos casos, definirse claramente como un problema de caso de prueba. De hecho, desde mi experiencia, definir el error como un caso de prueba roto hace que la discusión sea mucho, mucho más simple.
En lugar de escuchar a los expertos tratar de explicar un proceso comercial súper complejo, los expertos tienen que producir ejemplos concretos del proceso.
TDD requiere que los requisitos sean 100% correctos. En tales casos, uno podría esperar que se capturaran requisitos en conflicto durante la creación de pruebas. Pero el problema es que este no es el caso en un escenario complejo.
No usar TDD exige absolutamente que los requisitos sean 100% correctos. Algunos afirman que TDD puede tolerar requisitos incompletos y cambiantes, donde un enfoque que no sea TDD no puede funcionar con requisitos incompletos.
Si no usa TDD, la contradicción se encuentra tarde en la fase de implementación.
Si usa TDD, la contradicción se encuentra antes cuando el código pasa algunas pruebas y falla otras pruebas. De hecho, TDD le proporciona pruebas de una contradicción al principio del proceso, mucho antes de la implementación (y argumentos durante las pruebas de aceptación del usuario).
Tiene un código que pasa algunas pruebas y falla otras. Nos fijamos en sólo esas pruebas y que encuentre la contradicción. Funciona muy, muy bien en la práctica porque ahora los usuarios tienen que discutir sobre la contradicción y producir ejemplos consistentes y concretos del comportamiento deseado.