test - ¿Debo comenzar a usar TDD en un proyecto que ya no lo usa?

tdd vs bdd (11)

Tengo un proyecto en el que he estado trabajando durante un tiempo, uno de esos proyectos pequeños que me gustaría lanzar un día a la fuente abierta.

Ahora comencé el proyecto hace aproximadamente 12 meses, pero solo lo estaba trabajando a la ligera, recién comencé a concentrar mucho más de mi tiempo en él (casi todas las noches).

Debido a que es un marco como la aplicación, a veces tengo problemas con el sentido de la orientación debido a que no tengo nada que impulse mis decisiones de diseño y, a veces, termino creando funciones que son difíciles de usar o incluso encontrar. He estado leyendo sobre cómo hacer TDD y pensé que tal vez esto me ayudaría con algunos de los problemas que estoy teniendo.

Entonces, la pregunta es ¿crees que es una buena idea empezar a usar TDD en un proyecto que no lo usa ya?

EDITAR: Acabo de agregar un poco para aclarar lo que quiero decir con "sentido de la orientación", no era lo mejor decir sin una aclaración.

Absolutamente.

Introduzca TDD en el nuevo código y, si el tiempo lo permite, introduzca "Comentario Driven Design" con su código actual si aún no se ha probado.

Comente el bloque del código existente que necesita probar
Escribe tu prueba
Descomente su código original una declaración a la vez (si tiene un bloque if, descomente todo el bloque)
Determine si su código original finalmente pasa su prueba y si no, vuelva a escribir para pasar sus pruebas en consecuencia

Como han dicho otros, TDD no debería perjudicar un proyecto en progreso, pero piense detenidamente si está tentado de hacer una refactorización a gran escala solo para permitir las pruebas. Asegúrese de que los beneficios justifiquen el costo.

Estoy un poco preocupado de que "luches con un sentido de dirección". No sé que TDD te ayudará allí. Creo que es una gran ayuda para las decisiones de diseño de bajo nivel, pero no tanto para las decisiones de arquitectura. Agregar TDD a un proyecto sin dirección suena un poco como tener un bebé para salvar un matrimonio, imprudente. Espero haber leído mal tu intención.

En el peor de los casos, puede hacer TDD en cosas nuevas, mientras crea pruebas lentamente para su base de códigos existente.

En mi opinión, nunca es demasiado tarde para adoptar una mejor práctica, o para dejar caer una peor, así que yo diría "Sí, debes comenzar".

Sin embargo ... (siempre hay un "pero") ...

... una de las mayores ganancias de TDD es que impacta en su diseño, lo que le anima a mantener las responsabilidades separadas, las interacciones limpias, etc.

En este punto de su proyecto, puede que le resulte difícil obtener pruebas escritas para algunos aspectos de su marco. Sin embargo, no te rindas, incluso si no puedes probar algunas áreas, tu calidad será mejor para las áreas que puedes probar, y tus habilidades mejorarán para la experiencia.

Sí, absolutamente una buena idea para comenzar a hacer TDD.

Pagará un costo de puesta en marcha por al menos dos razones:

Aprendiendo una nueva habilidad Prueba de TDD / unidad.
Reequipando su código para que sea comprobable.

Tendrá que hacer algunas de las dos cosas, pero mientras trabaja si se encuentra luchando, piense en cuál de esas dos es la fuente del esfuerzo.

Pero el resultado final lo vale. Según lo que describes, este es un proyecto con el que tienes la intención de vivir por bastante tiempo. Recuerda eso cuando pierdes una hora aquí o allá. En un año, estará muy contento de haber hecho esta inversión tanto en su conjunto de habilidades como en la base de códigos.

Sí, nunca es demasiado tarde para comenzar a usar TDD. Introduje TDD en un proyecto comercial que ya se estaba ejecutando durante cinco años cuando me uní, y definitivamente fue una buena decisión.

Si eres nuevo en la técnica, probablemente deberías concentrarte en usarla para el código que estás escribiendo desde cero: nuevas clases, nuevos métodos, etc. Una vez que te acostumbras, comienza a escribir pruebas para el código que cambias. .

Para algunos de los códigos, este último podría resultar difícil, porque es poco probable que el código que ha escrito hasta ahora se escriba con capacidad de prueba en mente. Hay algunas técnicas para lidiar con eso, pero es probable que sea demasiado pronto para preocuparse por ellas.

Si te falta un sentido de dirección, sin embargo, dudo que TDD te ayude mucho. Es posible que desee examinar las Pruebas de aceptación, que son al menos tan importantes como las pruebas unitarias, y le ayudarán a centrarse en la funcionalidad del sistema en lugar de unidades de código individuales. El libro TDD de Lasse Koskela es una buena introducción a ambas técnicas.

Otra técnica que podría ayudarlo es el juego de planificación Extreme Programming, donde pone piezas de funcionalidad en fichas y las prioriza. Normalmente noto que sacarme ideas de la cabeza y ordenarlas por orden de prioridad me ayuda mucho a entender a dónde quiero ir después.

Sí.

Básicamente, no puede hacer ningún daño añadiendo TDD para cualquier código nuevo que escriba y cualquier cambio que realice en el código existente. Obviamente, sería complicado retroceder y adaptar pruebas precisas al código existente, pero ciertamente no estaría de más tratar de cubrir los casos de uso primarios.

¿Tal vez considere echar un vistazo al desarrollo de aplicaciones Brownfield en .NET ? Está lleno de consejos pragmáticos y prácticos para exactamente este escenario (una de las definiciones ofrecidas para "Brownfield" es "sin pruebas unitarias correctas").

Sí.

TDD hace que sea más fácil para otras personas entender el código, y le da a la aplicación un mejor diseño a lo largo del tiempo

En teoría, se suponía que debías probar primero, pero no lo hiciste. En este escenario, contrariamente a la opinión de los demás, no comenzaría con nuevas características.

Aproveche la regla 80:20, ejecute un generador de perfiles y coloque los casos de prueba en el fragmento de código llamado con más frecuencia.
Ponga pruebas alrededor de la casa joya, intestino, el código más importante.
Ponga a prueba el código de buggy de déjà vu recurrente, molesto y constante.
Ponga a prueba todos los errores que encuentre antes de corregir el error de la prueba fallida.

Advertencia: poner casos de prueba requerirá refactorización, lo que significa que debe arreglar algo que no se está rompiendo.

Si todavía te encantan las pruebas unitarias en este punto, serás Rojo, Verde, Refactorizar por tu cuenta.

Escribir exámenes para el código de trabajo existente que no planea cambiar no encaja con el impulso de TDD, que es escribir pruebas que le enseñen sobre el sistema que está construyendo.

Mi enfoque para incorporar TDD a mitad de camino ha sido:

escribir pruebas para todas las características nuevas, y
cuando cambie un fragmento de código, escriba una prueba que cubra la funcionalidad existente (para asegurarse de que lo entiendo), luego cambie la prueba antes de cambiar el código.

También puede ser beneficioso escribir pruebas para el código relacionado con el código que está cambiando; por ejemplo, si está alterando una clase principal, es posible que primero desee realizar pruebas en torno a clases para niños para protegerse del daño potencial.

Si deberías. Actualmente estoy trabajando en un proyecto que hasta hace poco no estaba cubierto con pruebas unitarias, pero decidimos que deberíamos comenzar a probar nuestro código, así que comenzamos a escribirlo ahora. Desafortunadamente, soy el único desarrollador que practica TDD, otros solo escriben pruebas después de escribir su código.
Aún así, descubrí que practicar TDD me ayuda a escribir mejor código, y lo escribo más rápido que antes. Ahora que aprendí a hacer TDD, no quiero volver a escribir el código de la forma en que solía hacerlo.