He leído muchas cosas sobre TDD pero todavía tengo dudas. Por ejemplo, tengo estos diagramas de clases:
Es un ejemplo simple, solo para aprender sobre TDD y simular objetos.
¿Qué prueba debo escribir primero? Producto , luego Línea y último, ¿ Orden ? Si hago eso, ¿debo usar Line and Product para probar Order o debo usar Mock Objects? ¿Cuándo debo usar Mock Objects? ¿Debo usar UML con XP y TDD?
Todavía no entiendo estas cosas.
Respuestas:
A juzgar por el diagrama, el Producto es una clase de datos tontos, sin funcionalidad para probar. Entonces comenzaría a escribir pruebas para (e implementar, estilo TDD) primero Line y luego Order, en la escala de dependencia. Por lo general, es sensato probar sus clases de nivel inferior antes de comenzar a trabajar en clases de nivel superior (es decir, que dependen del nivel inferior). Esto hace que la detección de errores sea más eficiente.
Si necesita usar objetos simulados depende de las dependencias reales de la clase probada. Si se trata de clases simples que puede crear instancias y configurar fácilmente con cualquier información / estado deseado requerido para sus pruebas, no necesita simulacros. (Este parece ser el caso de su diseño de ejemplo aquí.) Sin embargo, si alguna de las dependencias es difícil de inicializar / tiene dependencias extensas en sí misma / tiene efectos secundarios indeseables / depende de un recurso externo como un DB, entonces tiene sentido para usar un objeto simulado en su lugar.
No veo mucha necesidad de objetos simulados aquí. Como señalaron otros, los necesita principalmente si las dependencias son difíciles de configurar.
Por ejemplo, los usamos con proyectos de Ruby on Rails cuando probamos controladores y necesitábamos un inicio de sesión de usuario que hubiera requerido una llamada a otro controlador y almacenar parte de su información en una cookie. En este caso, es útil burlarse de un usuario conectado que devuelve verdadero cuando se le pregunta sobre un cierto privilegio de acceso.
Normalmente, para las pruebas, desea aislar el sistema / objeto bajo prueba, por lo que se burlaría de todo lo que esté fuera de eso. Entonces, usando su diagrama de clase, cuando pruebe un objeto de orden, use un simulacro para el objeto de línea. Al probar Line, use un simulacro de pedido y producto. Al probar el producto, use simulacro para Line.
"TDD es principalmente una técnica de diseño con un efecto secundario de garantizar que su código fuente se pruebe a fondo" - Scott W. Ambler
La idea es encontrar el diseño escribiendo pruebas unitarias. En su caso, parece que ya tiene el diseño en su lugar, lo que frustra el propósito de TDD (suponiendo que su diseño sea final).
En cuanto a burlarse. Si quiere burlarse, le sugiero que se burle del Producto cuando escriba pruebas para Línea y simule Línea cuando pruebe Pedido. Pero puede ser excesivo aquí. Personalmente trato de limitar la burla tanto como sea posible y la uso para desacoplar dependencias de clases externas (como instancias de bases de datos).