Sigo leyendo sobre personas que están "infectadas por la prueba", lo que significa que no solo "obtienen" TDD sino que no pueden vivir sin él. Han "tenido el cambio de imagen" por así decirlo. La pregunta es, ¿cómo me pongo así?¿Cómo me convierto en "prueba infectada" con TDD?
Parte del punto de ser "prueba infectada" es que has usado TDD lo suficiente y has visto los éxitos suficientes como para que no quieras codificar sin. Una vez que has pasado por un ciclo de pruebas escritas primero, luego codifica y refactoriza y ves que tus conteos de errores disminuyen y tu código mejora como resultado, no solo se vuelve de segunda naturaleza como dijo Zxaos, tienes dificultades para ir volver a Code First. Esto está siendo infectado por la prueba.
Aprenda sobre TDD para comenzar, y luego comience a integrarlo en su flujo de trabajo. Si usa las metodologías lo suficiente, verá que se convierten en una segunda naturaleza y comenzará a enmarcar todas sus tareas de desarrollo dentro de ese marco.
Además, comience a utilizar el marco J-Unit (o X-Unit) para el idioma de su elección.
Ya has leído sobre TDD; leer más no te emocionará.
En su lugar, necesita una verdadera historia de éxito personal.
He aquí cómo. Tome algún código de un módulo central, código que no dependa de sistemas externos o de muchas otras subrutinas. No importa cuán compleja o simple sea la rutina.
Luego, comience a escribir pruebas unitarias en su contra. (Supongo que tiene una xUnit o similar para su idioma.) Sea realmente desagradable con las pruebas: pruebe cada caso límite, pruebe max-int y min-int, pruebe null, cadenas de prueba y listas con millones de elementos, cadenas de prueba con caracteres coreanos y de control y árabe de derecha a izquierda y comillas y barras diagonales inversas, y períodos y otras cosas que tienden a romper las cosas si no se escapan.
Lo que encontrarás es ... ¡errores! Al principio, podrías pensar que estos errores no son importantes, aún no te has encontrado con estos problemas, tu código probablemente nunca haría esto, etc. Pero mi experiencia es que si continúas avanzando te sorprenderás. en la cantidad de pequeños problemas Finalmente, se hace difícil creer que ninguno de estos errores alguna vez causa un problema.
Además, obtienes una gran sensación de logro con algo que se hace realmente, muy bien. Sabemos que el código nunca es perfecto y rara vez está libre de errores, por lo que es agradable cuando hemos agotado tantas pruebas que realmente nos sentimos seguros. La confianza es un sentimiento agradable.
Finalmente, creo que el último evento que provocará el amor se producirá semanas o meses después. Tal vez esté solucionando un error o añadiendo una función o refactorizando algún código, y algo que haga romperá una prueba unitaria. "¿Huh?" dirá, sin entender por qué el nuevo cambio fue incluso relevante para la prueba rota. Entonces lo encontrarás y encontrarás la iluminación. Porque realmente no sabía que estaba descifrando el código, y las pruebas le salvaron.
¡Aleluya!
Una palabra, práctica! Hay algo de sobrecarga al hacer TDD y la forma de superarlo es practicar y asegurarse de que está usando herramientas para ayudar en el proceso. Necesitas aprender las herramientas como la palma de tu mano. Una vez que aprenda las herramientas para seguir el proceso que está aprendiendo, entonces hará clic y obtendrá fluidez con las pruebas de escritura primero para eliminar el código. Entonces serás "infectado por la prueba".
I answered una pregunta similar hace un tiempo. Es posible que desee comprobarlo también. Menciono algunas herramientas y explico el aprendizaje de TDD. De estas herramientas, Resharper y elegir un buen marco de burla son fundamentales para hacer TDD. No puedo enfatizar el aprendizaje de estas herramientas para estar de acuerdo con el marco de prueba que está utilizando lo suficiente.