Ejercicios de diferentes tipos de stub, mock, fake y spy. Validación por estado o interacción. Beneficios, ventajas y sus peligros. Cuando usarlo y cuando evitarlo.
Simulación de comportamientos heredados del framework en el Object Under Tests.
Reutilización para todo el equipo de desarrollo (fijar estándares en el equipo de desarrollo: extreme programming).
Simplifican el código de test sin hacer uso de librerías de generación de mocks.
Desarrollo de componentes ejecutados en un framework basado en componentes de contenedor.
Aunque los ejemplos se basan en el desarrollo de aplicaciones web con tecnología Java, tratan de transmitir las dificultades y soluciones para la aplicación de TDD en entornos no preparados para el unit testing (técnicas no ligadas al desarrollo de servlets).
También funcionan como ejemplos de como aplicar TDD en el desarrollo de la capa de presentación de una aplicación web.
Aunque siguiendo la filosofía de trasladar responsabilidades a la lógica de negocio, quedan con un código tan repetitivo, que conviene plantear si no sería mejor delegar las pruebas de los controladores a los test de integración.
¿Qué está realmente dirigiendo el desarrollo de la lógica de los controladores? ¿Las pruebas unitarias o la arquitectura que impone el propio framework utilizado?
Arquitectura MVC usando sólo tecnologías nativas de J2EE:
Se desarrollara una arquitecta MCV sin el uso de frameworks de controlador frontal como Structs o SpringMVC (solo J2EE).
Una arquitectura MVC facilita el uso de TDD. Los controladores no deben tener absolutamente nada de lógica de negocio. Solo son "wrappers" de la capa de negocio.
La lógica de presentación se reduce a lo mínimo, y por tanto requiere menos unit testing.