unit testing - Aumento de la capacidad de prueba, al codificar con Bold para Delphi framework

unit-testing delphi-2007 (3)

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

Algunos de los capítulos tienen nombres de excusas que un desarrollador puede dar para explicar por qué es difícil probar el código antiguo, y contienen estudios de casos y formas sugeridas de abordar cada problema:

No tengo mucho tiempo y tengo que cambiarlo.
No puedo ejecutar este método en un arnés de prueba
Esta clase es demasiado grande y no quiero que se haga más grande.
Necesito cambiar un método de monstruo y no puedo escribir pruebas para ello.

También cubre muchas técnicas para romper dependencias; Algunos pueden ser nuevos para ti, y otros que quizás ya conozcas pero que aún no has pensado usar.

Antecedentes Trabajo en un equipo de 7 desarrolladores y 2 evaluadores que trabajan en un sistema logístico. Utilizamos Delphi 2007 y el desarrollo basado en modelos con Bold para Delphi como marco. El sistema ha estado en producción hace aproximadamente 7 años y tiene aproximadamente 1,7 millones de líneas de código. Lanzamos a producción después de 4-5 semanas y después de cada lanzamiento tenemos que hacer algunos parches para los errores que no encontramos. Esto es, por supuesto, irritante tanto para nosotros como para los clientes.

Pruebas actuales La solución es, por supuesto, pruebas más 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 muy 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 intenté las pruebas de unidad con DUnit, pero me rendí después de algunos días. Las unidades tienen conexiones demasiado fuertes.

Condiciones previas de las pruebas unitarias Creo que conozco algunas condiciones previas para las pruebas unitarias:

Escribe pequeños métodos que hagan una cosa, pero hazlo bien.
No te repitas
Primero escriba la prueba que falla, luego escriba el código para que la prueba pase.
Las conexiones entre unidades deben estar sueltas. No deben saber mucho el uno del otro.
Utilizar inyección de dependencia.

Framework para usar Podemos actualizar a Delphi XE2, principalmente debido al compilador de 64 bits. He examinado Spring un poco, pero esto requiere una actualización del D2007 y eso no sucederá ahora. Talves el próximo año.

La pregunta La mayoría del código todavía no se prueba automáticamente. Entonces, ¿cuál es el mejor camino a seguir para aumentar la capacidad de prueba del código antiguo? ¿O tal vez es mejor 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 ahora y luego cambiar fácilmente a Delphi XE2 + Spring más tarde?

EDITAR: Acerca de la metodología de prueba actual para la prueba manual es simplemente "golpearla y tratar de romperla" como lo llama Chris .

Los requisitos para las pruebas unitarias automatizadas son exactamente esto:

use un marco de prueba de unidad (por ejemplo, DUnit).
utilizar algún tipo de marco burlón.

El artículo 2 es el difícil.

SECO, métodos pequeños, comenzar con una prueba y DI son todos azúcar. Primero necesitas comenzar la prueba unitaria. Agregue DRY, etc. a medida que avanza. El acoplamiento reducido ayuda a hacer que las cosas sean más fáciles de probar por unidad, pero sin un esfuerzo de refactorización gigante, nunca reducirá el acoplamiento en su base de código existente.

Considere escribir pruebas para cosas que son nuevas y cosas que se cambiaron en el lanzamiento. Con el tiempo obtendrás una base razonable de pruebas unitarias. Las cosas nuevas y cambiantes también pueden ser refactorizadas (o bien escritas).

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 la prueba de la unidad. Para los evaluadores de control de calidad, necesitará una herramienta (existen, pero no se me ocurre ninguna) que les permita ejecutar pruebas automatizadas (que no son pruebas unitarias).

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

Además, no dijiste mucho sobre 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 esperado? ¿O simplemente lo "golpean y tratan de romperlo"?

En mi opinión, las pruebas Dunit son difíciles de hacer con muchas dependencias como bases de datos, comunicaciones, etc. Pero es factible. He creado clases de DUnit que ejecutan automáticamente los scripts de configuración de la base de datos (busque un archivo .sql con el mismo nombre que la clase que se está probando, ejecute el sql, luego la prueba) y ha sido muy efectivo. Para las comunicaciones SOAP, tengo un servicio de mockservice de SoapUI que devuelve resultados fijos, por lo que puedo probar mis comunicaciones.
Lleva trabajo, pero vale la pena.