2009-06-19 9 views
6

Actualmente estoy en un término cooperativo para trabajar en un proyecto que está a punto de finalizar con otro alumno cooperativo. Dado que este proyecto se ha transmitido de la cooperativa a la cooperativa, se han seguido prácticas deficientes en el camino y las pruebas se han dejado hasta el final. Decidí que me gustaría escribir pruebas unitarias para aprender algo nuevo mientras estoy probando.Pasos a seguir para integrar lentamente las pruebas unitarias en un proyecto

Sin embargo, estoy trabajando en una aplicación estrechamente acoplada de 3 niveles que parece imposible de probar en su forma actual. No quiero echar al otro estudiante de la cooperativa sin conocimiento de ninguno de estos conceptos al refactorizar el código más allá del reconocimiento de la noche a la mañana. Entonces, ¿qué pasos debo tomar para llevar lentamente el código hacia la capacidad de prueba de la unidad? ¿Debo primero implementar 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 erróneo y no debería haber ningún problema en absoluto. Soy nuevo en esto :)

+1

personalmente, si usted cree que puede hacer una enorme cantidad de refactorización, por qué no conseguir que el otro estudiante para venir a sentarse con usted y sobre la marcha, él/ella puede pedir preguntas y tal vez él/ella tiene algunas ideas propias. Nuestra industria se mueve rápido, como estoy seguro que sabes, por lo que tu compañero no se encontrará con otros desarrolladores tan indulgentes como tú. He agregado esto como un comentario porque en realidad no responde a su pregunta sobre las pruebas unitarias. Solo quería darle algo más en qué pensar. ¡Buena suerte! – StevenMcD

+0

@FailBoy gracias por el comentario :) Esta es definitivamente una opción. Sin embargo, no parecen demasiado interesados ​​en trabajar en las cosas lado a lado. Simplemente parece ser un rasgo de personalidad. Preferirían revisar cualquier cambio que haga y hacer preguntas después. Simplemente no quiero enviarlos a un estado de shock y tengo que deshacer todos mis cambios de código. – Chris

Respuesta

7

Working Effectively with Legacy Code por las plumas Michael

difícil saber si la implementación de un modelo de fábrica hará ningún bien, depende de lo que el código está haciendo :)

+5

+1 Aquí hay un resumen de lo que obtendría en el libro y cómo crear una "costura" que puede probar con seguridad: http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf –

1

Es muy difícil comenzar nuevas prácticas de desarrollo a mitad de camino a través de un proyecto. En el pasado, cuando trabajaba en proyectos que no habían sido probados desde el principio, un buen enfoque es establecer la regla de que "el nuevo código debe tener pruebas unitarias", pero no ejerce presión sobre las pruebas unitarias escrito para código antiguo.

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

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

Comience por crear su conjunto de prueba de unidad, (o proyecto o lo que sea) sin pruebas en él. Luego, busque un área pequeña de código que esté bastante bien definida y separada, y escriba algunas pruebas de unidad para esa área. Haga que su codirector también eche un vistazo y comience a ejecutar algunas de las "mejores prácticas", como ejecutar las pruebas unitarias cada vez que se ingresa un código (de ser posible, automáticamente).

Una vez que tenga ese funcionamiento, puede comenzar lentamente a agregar más.

La clave es lenta. Y como dije, es más fácil eximir el código anterior de las pruebas, para empezar. Siempre puede regresar a ella más adelante una vez que su equipo haya comprendido la idea de las pruebas unitarias y haya mejorado al escribirlas.

+0

Esta es una gran idea. Sin embargo, la mayoría de la funcionalidad ya se ha implementado. En general, estoy haciendo esto para tener experiencia en pruebas unitarias, ya que las pruebas manuales para las próximas dos semanas serían bastante secas. – Chris

+0

Por lo que parece, este es un proyecto de estudiante, ¿sí? Si dices que la mayor parte de la funcionalidad está completa, no puedes quedarte tanto tiempo, solo haz una copia de seguridad y sigue adelante y haz los cambios. Si su pareja no comprende, no importa, los proyectos casi terminan de todos modos. Obtienes tu experiencia, y el proyecto todavía está bien.Escriba en su escrito que ha aprendido que las pruebas unitarias se implementarán mejor desde el principio la próxima vez = :) –

+0

¡Esto es correcto! Mas o menos. Es una cooperativa del gobierno, así que las cosas se mueven lentamente. Hasta que el jefe revise la aplicación y nos diga qué cambios quiere (lo que podría llevar meses), estamos en modo de prueba. En este punto, el sistema puede volverse hacia adentro. Las pruebas unitarias no solo me ayudarán a aprender, sino que también facilitarán este proceso, con suerte. Simplemente no quiero ser irrespetuoso y dejar la otra cooperativa a oscuras :) – Chris

1

¿Cómo escribir una serie de pruebas de recuadro negro alrededor de los principales piezas de funcionalidad en tu código? Como mencionas que se trata de un proyecto ASP.NET, puedes utilizar un marco como WaitN o Selenium para automatizar un navegador web. Esto le proporciona un conjunto de funcionalidades de línea de base que debe permanecer constante sin importar cuánto cambie el código.

Una vez que tenga un buen número de pruebas probando la funcionalidad de alto nivel de su proyecto, comenzaría a bucear en el código, y como menciona Simon P. Stevens, trabaje lentamente. Obtenga una copia (gratuita) de Refactor! for Visual Basic, para que pueda realizar automáticamente algunas refactorizaciones básicas, como Extraer método. Puede aumentar drásticamente la capacidad de prueba sin cambiar ninguna funcionalidad simplemente dividiendo trozos de código más grandes en trozos más pequeños y comprobables.

2

Working Effectively with Legacy Code 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 proporciona tutoriales prácticos de lotes de técnicas conservadoras -necesarias porque está trabajando sin una red de seguridad- para poner el código bajo prueba. Tabla de contenidos:

  • Parte: I La mecánica de cambio
    • Capítulo 1. Cambio de Software
      • Cuatro razones para cambiar el software
      • cambio arriesgado
    • Capítulo 2 . Trabajar con comentarios
      • ¿Qué es la prueba unitaria?
      • orden superior Prueba
      • Revestimientos de prueba
      • El legado Código cambio de algoritmo
    • Capítulo 3. Detección y separación
      • Falsificación Colaboradores
    • Capítulo 4. La costura Modelo
      • una hoja enorme de texto
      • costuras
      • Tipos de juntas
    • Capítulo 5. Herramientas
      • Automatizado refactoración Herramientas
      • Mock Objects
      • Arneses
      • pruebas unitarias
      • general Arnés de prueba
  • Parte: II cambiar el software
    • Capítulo 6. Yo no tengo mucho tiempo y tengo que cambiarlo
      • Método Sprout
      • Sprout Clase
      • Wrap Método
      • Envoltura clase
      • Sumario
    • Capítulo 7.Se tarda una eternidad para hacer un cambio
      • Comprender
      • Tiempo Lag
      • Rompiendo Dependencias
      • Resumen
    • Capítulo 8. ¿Cómo añadir una característica?
      • Test-Driven Development (TDD)
      • Programación por Diferencia
      • Resumen
    • Capítulo 9. No puede obtener esta clase en un instrumento de prueba
      • El caso de el parámetro irritante
      • El caso de la dependencia oculta
      • El caso de la construcción Blob
      • El caso de la irritante Global Dependencia
      • El caso de la horrible Incluir dependencias
      • El caso de la cebolla Parámetro
      • El caso del alias de parámetros
    • Capítulo 10. no puede ejecutar este método en un instrumento de prueba
      • el caso del método oculto
      • El caso del "útil" función idioma
      • El caso del efecto indetectable lateral
    • Capítulo 11. Necesito hacer un cambio. ¿Qué métodos debo probar?
      • Razonamiento sobre los efectos
      • razonamiento hacia adelante
      • Efecto Propagación
      • Herramientas para Efecto Razonamiento
      • Aprender de Análisis Efecto
      • Simplificando el efecto Sketches
    • Capítulo 12. Necesito Haga muchos cambios en un área. ¿Debo romper las dependencias para todas las clases involucradas?
      • Intercepción Puntos
      • A juzgar Diseño con puntos de pellizco
      • Pinch Point Trampas
    • Capítulo 13.Necesito hacer un cambio, pero no sé qué pruebas escribir Caracterización Pruebas de
      • Clases Caracterización
      • Pruebas específicas
      • una heurística para la escritura Caracterización Prueba
    • Capítulo 14. Las dependencias de las bibliotecas me están matando
    • Capítulo 15. Mi aplicación es todas las llamadas API
    • Capítulo 16. No entiendo el código Lo suficientemente bien como para cambiarlo
      • Notas/Bosquejando
      • listado de marcado
      • arañazos Refactorizando
      • eliminar el código no utilizado
    • Capítulo 17. Mi aplicación no tiene una estructura
      • Decir la Historia del sistema
      • Naked CRC
      • Conversación Escrutinio
    • Capítulo 18. Código de prueba Mi está en el camino
      • Convenciones de nomenclatura Clase
      • Prueba de Ubicación
    • Capítulo 19. Mi proyecto no está orientado a objetos. ¿Cómo realizo cambios seguros?
      • Un caso fácil
      • Un duro caso
      • agregar nuevo comportamiento
      • Tomando ventaja de Orientación a Objetos
      • está todo orientado a objetos
    • Capítulo 20. Esta clase es demasiado grande y No quiero que se vuelva más grande
      • Seein g Responsabilidades
      • otras técnicas
      • se mueven adelante
      • Después de extracto de Clase
    • Capítulo 21. Estoy cambiando el mismo código por todo el lugar
      • Primeros pasos
    • Capítulo 22.Tengo que cambiar de un método de Monster y no puedo escribir pruebas para ejercer
      • variedades de monstruos
      • Entrando monstruos con soporte automatizado Refactoring
      • El Refactoring Manual Desafío Estrategia
    • Capítulo 23. ¿Cómo sé que no estoy rompiendo nada?
      • hyperaware Edición
      • un solo objetivo Edición
      • Preserve Firmas
      • Magro en el compilador de
    • Capítulo 24. Nos sentimos abrumados. No va a ser mejor Parte
  • : Técnicas III de Dependencia-Rompiendo
    • Capítulo 25.Técnicas de dependencia-Breaking
      • Adaptar Parámetro
      • Break Out método de objeto
      • Definición Finalización
      • Encapsulate Global Referencias
      • Expose Método estático
      • Extracto y anular llamada
      • Extraer y reemplazar el método de fábrica
      • Extraer y anular Getter
      • Extracto de implementador
      • Extracto de interfaz
      • Introducir Instancia Delegador
      • Introducir estático Setter
      • Enlace Sustitución
      • Parameterize Constructor
      • Parameterize Método
      • Primitivize Parámetro
      • Pull Up Función
      • empuje hacia abajo Dependencia
      • reemplazar la función de puntero de función
      • se reemplaza la referencia global con Getter
      • Subclase y reemplazar el método
      • sustituyen Instancia variable
      • Redefinición Plantilla
      • Redefinición texto
  • Apéndice: Refactorización
    • Extraer método
Cuestiones relacionadas