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.
La prueba de la unidad no requiere datos "grandes" simulados. Requiere suficientes datos simulados para probar los escenarios y nada más.
Además, los programadores realmente perezosos piden a los expertos en la materia que creen hojas de cálculo simples de los distintos casos de prueba. Solo una simple hoja de cálculo.
Luego, el programador perezoso escribe una secuencia de comandos simple para transformar las filas de la hoja de cálculo en casos de prueba de unidad. 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 punto de TDD es diseñar cosas para probabilidad (Test Drive Development). Si la GUI es así de compleja, entonces debe ser rediseñada para que sea más simple y más comprobable. Más simple también significa más rápido, más fácil de mantener y más flexible. Pero en su mayoría más simple significará más verificable.
Tengo experiencia en que TDD funciona bien si lo limita a una lógica de negocios simple. Sin embargo, la lógica de negocios 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 cierto.
Sin embargo, ayudar a los expertos en la materia a proporcionar los casos de prueba principales en una forma simple (como una hoja de cálculo) realmente ayuda.
Las hojas de cálculo pueden llegar a ser bastante grandes. Pero está bien, ya que utilicé un sencillo 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 iba a suceder. 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 más simple.
En lugar de escuchar a los expertos que intentan explicar un proceso de negocio súper complejo, los expertos tienen que producir ejemplos concretos del proceso.
TDD requiere que los requisitos sean 100% correctos. En tales casos, se podría esperar que se capturaran los requisitos en conflicto durante la creación de las pruebas. Pero el problema es que este no es el caso en un escenario complejo.
No usar TDD obliga absolutamente a que los requisitos sean 100% correctos. Algunos afirman que TDD puede tolerar requisitos incompletos y cambiantes, donde un enfoque no 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 anteriormente cuando el código pasa algunas pruebas y falla otras pruebas. De hecho, TDD le brinda a usted una prueba de una contradicción anterior en el proceso, mucho antes de la implementación (y los argumentos durante las pruebas de aceptación del usuario).
Tienes un código que pasa algunas pruebas y falla otras. Miras solo esas pruebas y encuentras la contradicción. Funciona realmente 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.