Pasos a seguir para integrar lentamente las pruebas unitarias en un proyecto

Question

Actualmente estoy en un término cooperativo trabajando en un proyecto a punto de finalizar con otro estudiante cooperativo. Dado que este proyecto se ha pasado de cooperativa a cooperativa, se han tomado malas prácticas en el camino y se han dejado las pruebas hasta el final. He decidido que me gustaría escribir pruebas unitarias para aprender algo nuevo durante las pruebas.

Sin embargo, estoy trabajando en una aplicación de 3 niveles, estrechamente acoplada, que parece imposible probar la unidad en su forma actual. No quiero descartar al otro estudiante cooperativo sin conocimiento de ninguno de estos conceptos refactorizando el código más allá del reconocimiento de la noche a la mañana. Entonces, ¿qué pasos debo tomar para tirar lentamente el código hacia la capacidad de prueba de la unidad? ¿Debería implementar primero un patrón de fábrica y dejar que el otro estudiante se familiarice con eso antes de seguir adelante?

Mis disculpas si mi conocimiento es defectuoso y no debería haber ningún problema. Soy nuevo en esto :)

Answer 1

Trabajando efectivamente con código heredado por Michael Feathers

Difícil saber si implementar un patrón de fábrica servirá de algo, depende de lo que esté haciendo el código :)

Answer 2

Trabajando eficazmente con código heredado de Michael Feathers (también disponible en Safari si tiene una suscripción) es un excelente recurso para su tarea. El autor define el código heredado como código sin pruebas unitarias, y ofrece tutoriales prácticos de lotes de técnicas conservadoras & # 8212; necesarias porque está trabajando sin una red de seguridad & # 8212; para poner el código bajo prueba. Tabla de contenido:

• Parte: I La Mecánica del Cambio
  • Capítulo 1. Cambio de software
    • Cuatro razones para cambiar el software
    • Cambio arriesgado
  • Capítulo 2. Trabajar con comentarios
    • ¿Qué son las pruebas unitarias?
    • Pruebas de nivel superior
    • Cubiertas de prueba
    • El algoritmo de cambio de código heredado
  • Capítulo 3. Detección y separación
    • Fingiendo colaboradores
  • Capítulo 4. El modelo de costura
    • Una enorme hoja de texto
    • Costuras
    • Tipos de costura
  • Capítulo 5. Herramientas
    • Herramientas de refactorización automatizadas
    • Objetos simulados
    • Arneses de prueba de unidad
    • Arnés de prueba general
• Parte: II Cambio de software
  • Capítulo 6. No tengo mucho tiempo y tengo que cambiarlo
    • Método de germinación
    • Clase de brotes
    • Método de ajuste
    • Clase de ajuste
    • Resumen
  • Capítulo 7. Se necesita para siempre hacer un cambio
    • Comprensión
    • Tiempo de retraso
    • Rompiendo dependencias
    • Resumen
  • Capítulo 8. ¿Cómo agrego una función?
    • Desarrollo guiado por pruebas (TDD)
    • Programación por diferencia
    • Resumen
  • Capítulo 9. No puedo incluir esta clase en un arnés de prueba
    • El caso del parámetro irritante
    • El caso de la dependencia oculta
    • El caso del blob de construcción
    • El caso de la dependencia global irritante
    • El caso de las horribles dependencias de inclusión
    • El caso del parámetro de cebolla
    • El caso del parámetro con alias
  • Capítulo 10. No puedo ejecutar este método en un arnés de prueba
    • El caso del método oculto
    • El caso del " Útil " Característica del idioma
    • El caso del efecto secundario indetectable
  • Capítulo 11. Necesito hacer un cambio. ¿Qué métodos debo probar?
    • Razonamiento sobre los efectos
    • Razonamiento hacia adelante
    • Propagación del efecto
    • Herramientas para el razonamiento de efectos
    • Aprendiendo del análisis de efectos
    • Simplificar bocetos de efectos
  • Capítulo 12. Necesito hacer muchos cambios en un área. ¿Tengo que romper dependencias para todas las clases involucradas?
    • Puntos de intercepción
    • Juzgar diseño con puntos de pellizco
    • Trampas de puntos de pellizco
  • Capítulo 13. Necesito hacer un cambio, pero no sé qué pruebas escribir Pruebas de caracterización
    • Caracterización de clases
    • Pruebas dirigidas
    • Una heurística para escribir pruebas de caracterización
  • Capítulo 14. Las dependencias de las bibliotecas me están matando
  • Capítulo 15. Mi aplicación es todas las llamadas a la API
  • Capítulo 16. No entiendo el código lo suficiente como para cambiarlo
    • Notas / Bocetos
    • Marcado de listado
    • Refactorización de arañazos
    • Eliminar código no utilizado
  • Capítulo 17. Mi aplicación no tiene estructura
    • Contar la historia del sistema
    • CRC desnudo
    • Escrutinio de conversación
  • Capítulo 18. Mi código de prueba está en el camino
    • Convenciones de nomenclatura de clase
    • Ubicación de prueba
  • Capítulo 19. Mi proyecto no está orientado a objetos. ¿Cómo hago cambios seguros?
    • Un caso fácil
    • Un estuche rígido
    • Agregar un nuevo comportamiento
    • Aprovechando la orientación a objetos
    • Todo está orientado a objetos
  • Capítulo 20. Esta clase es demasiado grande y no quiero que se haga más grande
    • Ver responsabilidades
    • Otras técnicas
    • Avanzando
    • Después de la clase de extracto
  • Capítulo 21. Estoy cambiando el mismo código por todas partes
    • Primeros pasos
  • Capítulo 22. Necesito cambiar un método Monster y no puedo escribir pruebas para él
    • Variedades de monstruos
    • Abordar monstruos con soporte de refactorización automatizado
    • El desafío de refactorización manual
    • Estrategia
  • Capítulo 23. ¿Cómo sé que no estoy rompiendo nada?
    • Edición de Hyperaware
    • Edición de un solo objetivo
    • Conservar firmas
    • Apóyate en el compilador
  • Capítulo 24. Nos sentimos abrumados. No va a mejorar nada
• Parte: III Técnicas de ruptura de dependencia
  • Capítulo 25. Técnicas de ruptura de dependencia
    • Adaptar parámetro
    • Objeto de método de ruptura
    • Finalización de definición
    • Encapsular referencias globales
    • Exponer método estático
    • Extraer y anular llamada
    • Extraer y anular el método de fábrica
    • Extraer y anular Getter
    • Implementador de extractos
    • Interfaz de extracción
    • Introducir delegador de instancias
    • Introducir Organizador estático
    • Sustitución de enlaces
    • Parametrizar constructor
    • Método de parametrización
    • Parámetro de primitivización
    • Función Pull Up
    • Reducir la dependencia
    • Reemplazar función con puntero de función
    • Reemplazar referencia global con Getter
    • Subclase y método de anulación
    • Reemplazar variable de instancia
    • Redefinición de plantillas
    • Redefinición de texto
• Apéndice: Refactorización
  • Método de extracción

Answer 3

Es muy difícil comenzar nuevas prácticas de desarrollo a la mitad de un proyecto. En el pasado, cuando trabajé en proyectos que no han sido probados desde el principio, un buen enfoque es establecer la regla de que 'el nuevo código debe tener pruebas unitarias' pero no presionar las pruebas unitarias siendo escrito para código antiguo.

Por supuesto, incluso esto es difícil cuando la estructura del proyecto no es adecuada para la comprobabilidad.

Mi mejor recomendación sería tomarlo en pequeños pasos.

Comience creando su conjunto de prueba de unidad (o proyecto o lo que sea) sin pruebas en él. Luego encuentre un área pequeña de código que esté bastante bien definida y separada, y escriba algunas pruebas unitarias para esa área. Haga que su codificador también eche un vistazo y comience a poner en marcha algunas 'mejores prácticas', como ejecutar las pruebas unitarias cada vez que se registra un código (automáticamente si es posible).

Una vez que tenga eso funcionando, puede comenzar lentamente a agregar más.

La clave es lenta. Y como dije, para empezar es más fácil hacer que el código antiguo esté exento de las pruebas. Siempre puede volver a él más tarde una vez que su equipo haya captado la idea de las pruebas unitarias y haya mejorado su redacción.

Answer 4

¿Qué tal escribir una serie de pruebas de recuadro negro alrededor de las principales funciones de su código? Como menciona que es un proyecto ASP.NET, puede usar un marco como WaitN o Selenium para automatizar un navegador web. Esto le brinda un conjunto básico de funcionalidades que deben permanecer constantes sin importar cuánto cambie el código.

Una vez que tenga una cantidad cómoda de pruebas que prueben la funcionalidad de alto nivel de su proyecto, comenzaré a sumergirme en el código y, como Simon P. Stevens menciona, trabaje lentamente . ¡Obtenga una copia (gratuita) de Refactor! para Visual Basic , por lo que podrá realizar automáticamente algunas refactorizaciones básicas, como el Método de extracción. Puede aumentar drásticamente la capacidad de prueba sin cambiar ninguna funcionalidad simplemente dividiendo fragmentos de código más grandes en fragmentos más pequeños y más comprobables.