tdd - que - Cómo cambiar su paradigma al desarrollo basado en pruebas
tdd vs bdd (6)
He estado escuchando sobre el desarrollo impulsado por pruebas desde hace un par de años, y nunca le presté demasiada atención desde un nivel práctico hasta hace poco cuando comencé a interesarme más en .NET MVC. He estado jugando mucho con MVC Storefront Sample , y me doy cuenta de lo genial y útil que puede ser el enfoque impulsado por la prueba. Sin embargo, he estado programando usando un enfoque de "prueba final" durante mucho tiempo, y cuando se trata de negocios, siempre puedo estimar mejor mi esfuerzo con el enfoque con el que estoy más familiarizado.
Supongo que aprender a utilizar el enfoque basado en pruebas es menos parecido a aprender otro lenguaje de programación, sino más bien a un cambio en la forma en que se acerca a establecer el marco y planificar los requisitos para crear una aplicación. No creo que pueda tomar un libro y comenzar un proyecto para uno de mis clientes usando TDD, supongo que mi introducción debe ser más metódica.
¿Cuál es la mejor manera para mí de cambiar mi mentalidad de planificación para construir una aplicación para que pueda ser efectiva con el desarrollo basado en pruebas en el menor tiempo posible?
Además de lo que dice S.Lott, mire cómo está estructurado MVC Storefront.
¿Cómo manejan las pruebas con datos que provienen de una base de datos? ¿Cómo manejan las pruebas de que el Controlador funciona correctamente? ¿Cómo manejan cuando una clase tiene otras dependencias?
Ver cómo TDD requiere que estructuremos un programa realmente ayudará, una vez que haya pasado los conceptos básicos de (???) Unidad
Incluso si está escribiendo código primero, pregúntese mientras lo escribe, "¿es esto comprobable?" Si no es así, entonces quizás quieras replantear tu diseño para la pieza de código que estás escribiendo. Si es así, continúe y termínelo y escriba algunas pruebas después. En este momento, estoy en la mentalidad de code-a-little, test-a-little.
La mejor forma de elegir TDD es seguir adelante y hacerlo. Esa es la única forma hasta ahora que logré que los compañeros de trabajo "se infecten con la prueba"; al menos en este momento usted tiene una buena apreciación de los beneficios por adelantado.
Sin embargo, desde un punto de vista más práctico, creo que ya ha resaltado una de las ideas clave: es un cambio en la planificación de los requisitos para crear una aplicación. Cualquiera que sea la metodología que esté utilizando actualmente, si ve una palabra como "requisito", puede pensar mentalmente "caso de prueba" y, al menos, tener la intención de escribir primero el caso de prueba. Pero al igual que las otras respuestas sugieren, TDD no es una decisión de todo o nada. Cualquier prueba que escriba, siempre que la escriba, antes o después, es útil. Del mismo modo, no piense que puede llegar a un estado en el que escriba todas las pruebas por adelantado: es un ciclo.
Uno de mis favoritos es el pseudocódigo, al final de este artículo en las preguntas frecuentes de JUnit . El estado de ánimo del caso de prueba es un ciclo infinito. Salta a cualquier lado, cualquier prueba que escribas te ayudará, y no te arrepentirás.
Todavía puedes probar el último. Está bien. Te perdonaremos
Aprenda cómo funcionan las herramientas de prueba de la unidad en su idioma actual.
Comienza a escribir pruebas unitarias para lo que sea que estés trabajando ahora.
Eventualmente, puedes pasar a code-a-little-test-a-little. Luego prueba un pequeño código un poco.
El desarrollo basado en pruebas puras es un ideal. Pragmáticamente, la mayoría de la gente prueba un código pequeño. Es más como un guiado de prueba o guiado por prueba, en lugar de una prueba.
Empezar ahora. Pon a prueba todo lo que tienes a mano.
No veo por qué no podrías simplemente comenzar a usar TDD. No necesita crear todo su código con la práctica, simplemente utilícelo para una clase al día o una hora al día para empezar. Cuando te sientas más cómodo, extiende la aplicación de la práctica a más de tu código.
También recuerde que TDD es más una estrategia de diseño que una estrategia de prueba. Esté abierto a lo que las pruebas le están diciendo sobre el código de producción. Siempre refactorice sin piedad, especialmente al principio, yerse al lado de demasiada refactorización, en caso de duda.
Si puede encontrar personas con ideas afines, considere dirigir un dojo de codificación; es una manera genial y divertida de aprender una nueva habilidad de programación: http://codingdojo.org/
Necesitas practicar
Puede comenzar con la programación de prueba primero . Diseñe el código tal como lo hace normalmente, tal vez no en detalles profundos, y empiece a implementar primero su prueba: comience con una clase que no tenga dependencias, vea cómo se puede probar, escriba una lista de las pruebas que pueda pensar. Comienza a escribir la prueba más simple. Luego escribe el código suficiente para hacerlo pasar. Cruza la prueba en tu lista y escríbela, escribe el código.
Cuando tenga una idea para una nueva prueba o se haga una pregunta sobre cómo se comporta el código bajo ciertas condiciones, agregue una nueva prueba a su lista.
Te recomiendo que leas Test Driven Development ; es una muy buena introducción a TDD y también contiene una gran cantidad de materiales de referencia (llamados patrones).
Con respecto a las estimaciones, una cosa a tener en cuenta es que aunque escribir el código y las pruebas simultáneamente es un poco más largo que solo escribir el código, terminas con un código que funciona .
Algunos consejos más, una vez que comiences:
Agregue una nueva prueba de falla antes de solucionar cualquier problema en el código.
Esfuércese por nunca escribir ninguna línea de código sin tener una prueba de falla; ese es el objetivo final.