Nunca utilicé un mecanismo de prueba automatizado en ninguno de mis proyectos y siento que me falta mucho. Quiero mejorarme a mí mismo, así que tengo que comenzar a abordar algunos problemas que he estado descuidando de esta manera y probar Git en lugar de estar atascado en SVN.
¿Cuál es una buena manera de aprender TDD? Probablemente usaré Eclipse para programar en Java. He oído hablar de JUnit, pero no sé si hay algo más que deba considerar.
Respuestas:
Podrías comenzar trabajando en la codificación de katas . Elija un algoritmo (por ejemplo, conversión de números decimales a romanos, puntuación de un juego de bolos, juego de la vida de Conway, etc.) e intente utilizar TDD para trabajar en la solución.
Es probable que la estructura de su solución sea muy simple (mucho más simple que su código de producción del mundo real): una clase para el dispositivo de prueba y una clase que contiene el algoritmo bajo prueba. Y la clase bajo prueba que no tiene dependencias es otra ventaja. Puede utilizar la simplicidad de esta configuración para familiarizarse rápidamente con el bucle refactor rojo-verde.
La herramienta que use para sus katas TDD realmente no importa siempre y cuando se apegue a los principios. Sin embargo, el complemento JUnit para Eclipse es muy fácil de usar, por lo que es una excelente opción.
Familiarícese con AAA , lea sobre esto, lea sobre los problemas que vienen con el desarrollo basado en pruebas ( diseño para pruebas frente a herramientas de alto costo para que el diseño no importe). Aprenda la inyección de dependencias para que la eliminación de dependencias externas para las pruebas sea más simple.
Aquí hay una buena descripción de las notas que tomé mientras leía El arte de las pruebas unitarias
http://imaginarydevelopment.blogspot.com/2010/01/unit-testing-reference.html
Realmente no hay sustituto para simplemente agarrar un arnés de prueba (como NUnit), leer algo de la literatura y luego ensuciarse las manos.
Como James T. Kirk dijo una vez: "Aprendemos haciendo".
Recomiendo este libro: Creciente software orientado a objetos guiado por pruebas
Tiene un ejemplo trabajado que recorre el libro y proporciona una visión muy coherente de cuándo se debe crear la prueba, qué deben contener y cómo se deben construir y refactorizar.
Mira este enlace . Es el blog de Bob Martin sobre TDD: excelente material para hacerle entender (o darle otra perspectiva) pensar en TDD.