Debería empezar a usar TDD en un proyecto que ya no lo usa

Question

Tengo un proyecto en el que he estado trabajando por un tiempo, solo uno de esos proyectos pequeños que me gustaría lanzar un día para abrir el código fuente .

Ahora comenzó el proyecto hace unos 12 meses, pero yo sólo estaba trabajando en la ligera, sólo han comenzado a concentrarse mucho más de mi tiempo en él (casi todas las noches).

Debido a que es una aplicación como framework, a veces tengo dificultades con el sentido de la orientación debido a que no tengo nada que impulse mis decisiones de diseño y algunas 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.

Así que la pregunta es ¿cree que es una buena idea comenzar a usar TDD en un proyecto que aún no lo utilizan.

EDIT: acabo de haber añadido un poco para aclarar lo que quiero decir por la lucha con un "sentido de la orientación", de forma adecuada no era el mejor que se puede decir sin aclaración.

Answer 1

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

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

... uno de los mayores beneficios de TDD es que impacta en su diseño, que le anima a mantener reponsibilties separan, interacciones limpia y así.

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.

Answer 2

Sí.

Básicamente, no se puede hacer ningún daño mediante la adición de TDD para cualquier nuevo código 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 consideran echar un vistazo a Brownfield Application Development in .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").

Answer 3

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

Answer 4

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

Usted pagará un costo de puesta en marcha durante al menos dos razones:

1. El aprendizaje de una nueva prueba de habilidades TDD/unidad.
2. Retrofitting your code to be testable.

Tendrá que hacer algunas de ambas cosas, pero como trabaja si se encuentra luchando, piense en cuál de las 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.

Answer 5

Como han dicho otros, TDD no debería dañar 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 "tengas problemas con el sentido de la orientació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.

Answer 6

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 utilizarla 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 código que cambias

Para algunos de los códigos, este último podría ser difícil, ya que 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 las técnicas ambas.

Otra técnica que podría ayudarte es el juego de planificación Extreme Programming, donde colocas piezas de funcionalidad en fichas y las priorizas. 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.

Answer 7

Sí.

TDD hace que sea más fácil para otras personas a entender el código, así como da la aplicación de un mejor diseño con el tiempo

Answer 8

Absolutamente.

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

• comentario a cabo el bloque de código existente que necesita para poner a prueba
• Escriba su prueba
• Descomentar su código original de una instrucción a la vez (si tiene un bloque if, elimine todo el bloque)
• Determinar si su código original en última instancia, pasa la prueba y si no, volver a escribir a pasar sus pruebas en consecuencia

Answer 9

pruebas de escritura para existente, código que no tiene intención de cambiar de trabajo no encaja con la idea central de TDD, que es escribir pruebas que le enseñan sobre el sistema que está construyendo.

Mi acercamiento a la incorporación de TDD medio de la corriente ha sido:

• pruebas de escritura para todas las nuevas características y
• cuando se cambia una pieza de código, escribir una prueba que cubre la funcionalidad existente (para asegurarse de que lo entiendo), luego cambie la prueba antes de cambiar el código.

También puede ser beneficioso para escribir pruebas para el código relacionados con código que está cambiando - por ejemplo, si se está modificando una clase padre, es posible que desee construir pruebas alrededor de las clases hijas primero en protegerse de potencial dañar.

Answer 10

Sí, 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.

Answer 11

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 a prueba alrededor de la casa joya, tripa, el código más importante.
• Ponga a prueba el molesto, siempre interrumpido y recurrente código déjà vu buggy.
• Ponga a prueba todos los errores que encuentre antes de solucionando el error de la prueba de falla.

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

Si aún te encantan las pruebas unitarias en este punto, serás rojo, verde, refactorizar por tu cuenta.