Aumento de la capacidad de prueba, al codificar con Bold for Delphi framework

Question

Antecedentes Trabajo en un equipo de 7 desarrolladores y 2 probadores que trabajan en un sistema logístico. Usamos Delphi 2007 y desarrollo modeldriven con Bold for Delphi como framework. El sistema ha estado en producción unos 7 años y tiene alrededor de 1,7 millones de líneas de código. Lanzamos a producción después de 4-5 semanas y después de casi cada versión tenemos que hacer algunos parches para los errores que no encontramos. Esto es irritante tanto para nosotros como para los clientes.

Prueba actual La solución es, por supuesto, más pruebas automáticas. Actualmente tenemos pruebas manuales. Un Testdbgenerator que comienza con una base de datos vacía y agrega datos de los métodos modelados. También tenemos Testcomplete que ejecuta algunos scripts básicos para probar la GUI. La falta de tiempo nos impide agregar más pruebas, pero los scripts también son sensibles a los cambios en la aplicación. Hace algunos años, realmente probé pruebas unitarias con DUnit, pero me di por vencido después de algunos días. Las unidades tienen conexiones muy fuertes.

condiciones previas Unidad de prueba creo que sé algunas condiciones previas para las pruebas unitarias:

• escribe el pequeño métodos que hacen una cosa, pero lo hacen bien.
• No te repitas.
• Primero escriba la prueba que falla, luego escriba el código para que pase la prueba.
• Las conexiones entre las unidades se sueltan. No deberían saber mucho el uno del otro.
• Usar inyección de dependencia.

Marco de usar Nos puede actualizar a Delphi XE2, principalmente debido a que el compilador de 64 bits. Miré un poco el Spring, pero esto requiere una actualización de D2007 y eso no sucederá ahora. Talves el próximo año.

La pregunta La mayoría del código aún no se ha probado automáticamente. Entonces, ¿cuál es el mejor camino a seguir para aumentar la capacidad de prueba del código anterior? ¿O tal vez lo mejor es comenzar a escribir pruebas solo para nuevos métodos? No estoy seguro de cuál es la mejor manera de aumentar las pruebas automáticas y los comentarios al respecto son bienvenidos. ¿Podemos usar D2007 + DUnit de vez en cuando para cambiar fácilmente a Delphi XE2 + Spring más tarde?

EDIT: Acerca de la metodología de prueba actual para las pruebas manuales es simplemente "libra y trata de romperla" como Chris llámala.

Answer 1

¿Quieres el libro de Michael Feathers, Working Effectively with Legacy Code. Muestra cómo introducir pruebas (de unidades) al código que no se escribió teniendo en cuenta la capacidad de prueba.

Algunos de los capítulos llevan el nombre de excusas un desarrollador podría dar pruebas de por qué código antiguo es difícil, y contienen estudios de casos y sugirió formas de abordar cada problema:

• yo no tengo mucho tiempo y tengo que cambiarlo
• no puedo ejecutar este método en un instrumento de prueba
• esta clase es demasiado grande y no quiero que nada más grande
• tengo que cambiar un método monstruo y No puedo escribir pruebas para eso.

También cubre muchas técnicas para romper dependencias; algunos pueden ser nuevos para usted, y algunos que quizás ya conozca pero que aún no haya pensado usar todavía.

Answer 2

Su equipo de pruebas es demasiado pequeño, IMO. He trabajado en equipos donde el departamento de control de calidad supera en número a los desarrolladores. Considere trabajar en "sprints" de trozos manejables (características, arreglos) que se ajustan en ciclos más pequeños. "Ágil" alentaría carreras de 2 semanas, pero puede ser demasiado apretado. De todos modos, mantendría al QA constantemente ocupado, trabajando más adelante de la ventana de lanzamiento. En este momento, sospecho que están inactivos hasta que les proporciones una gran cantidad de código, y luego están inundados. Con ciclos de liberación más cortos, puede mantener ocupados a más probadores.

Además, no dijo mucho acerca de su metodología de prueba.¿Tienen scripts estándar que ejecutan, donde verifican la apariencia y el comportamiento frente a la apariencia y el comportamiento esperados? ¿O simplemente "golpean y tratan de romperlo"?

IMO, las pruebas Dunit son difíciles de hacer con muchas dependencias como bases de datos, comunicación, etc. Pero es factible. Creé clases de DUnit que ejecutan automáticamente secuencias de comandos de configuración de base de datos (busque un archivo .sql con el mismo nombre que la clase que se está probando, ejecute el sql, luego procede la prueba), y ha sido muy eficaz. Para las comunicaciones SOAP, tengo un servicio de simulación SoapUI en ejecución que arroja resultados enlatados, por lo que puedo probar mis comunicaciones.
Toma trabajo, pero vale la pena.

Answer 3

Los requisitos para la unidad de pruebas automatizado son exactamente esto:

1. utilizan un marco de pruebas de unidad (por ejemplo, DUnit).
2. utiliza algún tipo de marco de burla.

El artículo 2 es el más difícil.

DRY, métodos pequeños, comienzan con una prueba, y DI son todos azúcar. Primero necesita comenzar las pruebas unitarias. Agregue DRY, etc. a medida que avanza. El acoplamiento reducido ayuda a que las cosas se prueben más fácilmente, pero sin un esfuerzo de refactorización gigante, nunca reducirá el acoplamiento en su base de códigos existente.

Considere la posibilidad de escribir pruebas para cosas nuevas y cosas que se modifican en el lanzamiento. Con el tiempo obtendrás una base razonable de pruebas unitarias. Las novedades y los cambios también se pueden refactorizar (o escribir bien).

Además, considere un proceso de compilación automatizado que ejecuta pruebas unitarias y envía un correo electrónico cuando se rompe la compilación.

Esto solo cubre las pruebas unitarias. Para los evaluadores de QA, necesitarán una herramienta (existen, pero no puedo pensar en ninguna) que les permita ejecutar pruebas automatizadas (que no son pruebas unitarias).