He leído muchas cosas sobre TDD pero todavía tengo dudas. Por ejemplo, tengo estos diagramas de clase:
Es un ejemplo simple, solo para aprender sobre TDD y los objetos simulados.
¿Qué prueba debo escribir primero? Producto , luego Línea y la última, ¿Orden ? Si hago eso, ¿debo usar Línea y Producto para probar Orden o debo usar Mock Objects? ¿Cuándo debo usar objetos simulados? ¿Debo usar UML con XP y TDD?
Todavía no entiendo estas cosas.
A juzgar por el diagrama, el producto es una clase de datos tontos, sin funcionalidad para probar. Así que comenzaría a escribir pruebas para (e implementar, estilo TDD) la primera línea y luego ordenar, en la escala de dependencias. Por lo general, es sensato que se analicen las clases de nivel inferior antes de comenzar a trabajar en las clases de nivel superior (es decir, que dependen del nivel inferior). Esto hace que la captura de errores sea más eficiente.
La necesidad de usar objetos simulados depende de las dependencias reales de la clase probada. Si estas son clases simples que puede crear y configurar fácilmente con los datos / estados deseados que se requieren 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 / 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 han señalado otros, los necesita principalmente si las dependencias son difíciles de configurar.
Por ejemplo, los usamos con los proyectos de Ruby on Rails cuando probamos los 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 simular un usuario registrado que devuelve verdadero cuando se le pregunta acerca de un cierto privilegio de acceso.
Normalmente, para las pruebas, desea aislar el sistema / objeto bajo prueba, por lo que se burlaría de cualquier cosa que esté fuera de eso. Entonces, al usar su diagrama de clase, al probar un objeto de orden, use un simulacro para el objeto de línea. Al probar la línea, utilice un simulacro para orden y producto. Al probar el producto, utilice simulacro para la línea.
"TDD es principalmente una técnica de diseño con un efecto secundario de garantizar que su código fuente sea probado en su totalidad" - Scott W. Ambler
La idea es encontrar el diseño escribiendo pruebas unitarias. En su caso, parece que ya tiene el diseño implementado, lo que en cierto modo anula el propósito de TDD (suponiendo que su diseño sea definitivo).
En cuanto a la burla. Si desea burlarse, le sugiero que se burle del Producto al escribir pruebas para la Línea y la Línea simulada al probar la Orden. Pero puede ser una exageración aquí. Personalmente, trato de limitar la burla tanto como sea posible, y lo uso para desacoplar dependencias de clases externas (como instancias de base de datos).
Lea otras preguntas en las etiquetas unit-testing tdd php mocking