Personalmente, descubrí que leer un ensayo JUnit o dos enfatizando que "usted escribe la prueba antes del código" fue suficiente para comenzar.
La parte más importante para aprender esta tecnología es escribir MUCHO código basado en pruebas , porque debes cambiar algunas de las formas más básicas de pensar en escribir código. Cosas como:
- Escribir la prueba antes del código te hace pensar por adelantado cómo invocarás tu código y recuperarás el resultado. Esto significa que primero diseñas la API en función de cómo la usarás. Esto frecuentemente resulta en una mejor API.
- Su estilo de codificación cambiará porque NECESITARÁ pensar de manera más modular, para poder probar partes del código en lugar de solo todo.
- También llegará a un punto en el que podrá extraer con confianza una parte importante e insertar una nueva parte en lugar de comportarse igual, porque su prueba pasó. Lo hice recientemente con una biblioteca de análisis de fechas, ya que el original era demasiado indulgente.
El mejor lugar para comenzar con poco, es con sus rutinas de servicios públicos. La próxima vez que necesite uno, simplemente diseñe eso con pruebas primero, escriba muchas pruebas que cubran todos sus casos de uso oficiales (incluido lo que debería suceder con valores nulos pasados, etc.), y cuando se implementen todos los casos de uso, debería poder usar directamente en su código, y tenga la seguridad de que funciona como se espera.
También es mi experiencia que las buenas pruebas pueden hacer un trabajo adicional como documentación, porque tiene un código muy conciso que dice exactamente cómo se comporta el código en diversas situaciones, lo que puede demostrarse fácilmente que es correcto (barra verde). Con comentarios cuidadosos no lo haces mucho mejor que eso.
Para Java, la versión 4 de jUnit es realmente agradable.