Consejos para probar la aplicación heredada intensiva en datos

Question

Estoy trabajando en una aplicación heredada muy grande que requiere muchos datos. Tanto el código base y amp; La base de datos es masiva en escala. Gran parte de la lógica empresarial se extiende a todos los niveles, incluidos los procedimientos almacenados.

¿Alguien tiene alguna sugerencia sobre cómo comenzar a aplicar " unit " ¿Pruebas (técnicamente pruebas de integración porque necesitan probar a través de niveles para un solo aspecto de casi cualquier proceso dado) en la aplicación de una manera eficiente? La arquitectura actual no admite fácilmente ningún tipo de inyección o burla. Se está escribiendo un nuevo código para facilitar las pruebas, pero ¿qué pasa con el código heredado? Debido a la fuerte dependencia de los datos en sí y la lógica de negocios en la base de datos, actualmente estoy usando SQL inline para encontrar datos para probar, pero estos requieren mucho tiempo. Crear vistas y / o procedimientos almacenados no será suficiente.

¿Qué enfoques ha tomado (si corresponde)? Que funciono Lo que no & amp; ¿por qué? Cualquier sugerencia sera apreciada. Gracias.

Answer 1

Obtenga una copia de Trabajando eficazmente con código heredado por Michael Feathers. Está lleno de consejos útiles para trabajar con bases de código grandes y no probadas.

Otro buen libro es Patrones de reingeniería orientados a objetos . La mayor parte del libro no es específica del software orientado a objetos. El texto completo está disponible para su descarga gratuita en formato PDF.

Desde mi propia experiencia: intente ...

• Automatizar la compilación y la implementación
• Obtenga el esquema de la base de datos en el control de versiones, si aún no lo está. Por lo general, las bases de datos incluyen datos de referencia que el código transaccional necesita para existir antes de que pueda funcionar. Obtenga esto también bajo control de versiones. Herramientas como dbdeploy pueden ayudarlo a reconstruir fácilmente un esquema y datos de referencia a partir de una secuencia de deltas.
• Instale una versión de la base de datos (y cualquier otro servicio de infraestructura) en su estación de trabajo de desarrollo. Esto le permitirá trabajar en la base de datos sin tener que pasar continuamente por los DBA. También es más rápido que usar un esquema en un servidor compartido en un centro de datos remoto. Todos los principales servidores de bases de datos comerciales tienen versiones de desarrollo gratuitas (como en cerveza) que funcionan en Windows (si está atrapado en la difícil situación de desarrollar en Windows e implementar en Unix).
• Antes de comenzar a trabajar en un área del código, escriba pruebas de extremo a extremo que cubran aproximadamente el comportamiento del área en la que está trabajando. Una prueba de extremo a extremo debe ejercitar el sistema desde el exterior, controlando su interfaz de usuario o interactuando a través de los servicios de red, por lo que no necesitará cambiar el código para ponerlo en su lugar. Actuará como una prueba de regresión (imperfecta) y le dará más confianza para refactorizar las partes internas del sistema hacia una estructura que sea más fácil para la prueba unitaria.
• Si hay planes de prueba manuales, léalos y vea qué se puede automatizar. La mayoría de los planes de prueba manuales están casi totalmente escritos y también lo son los frutos para la automatización
• Una vez que tenga cobertura de pruebas de extremo a extremo, refactorice el código en unidades más libremente acopladas a medida que lo modifica y / o extiende. Rodee esas unidades con pruebas unitarias.

Cosas a evitar:

• Copiar datos de la base de datos de producción en el entorno que utiliza para las pruebas automatizadas. Esto hará que sus pruebas sean impredecibles. Claro, ejecute el sistema contra una copia de los datos de producción, pero úselo para pruebas exploratorias, no para pruebas de regresión.
• Revertir las transacciones al final de las pruebas para aislar las pruebas entre sí. Esto no probará el comportamiento que solo ocurre cuando se confirman las transacciones, y desechará los datos que son valiosos para diagnosticar fallas en las pruebas. En cambio, las pruebas deben garantizar que la base de datos se encuentre en un estado inicial conocido cuando comiencen.
• Crear un "pequeño" conjunto de datos para pruebas para ejecutar. Esto hace que las pruebas sean difíciles de entender porque no pueden leerse como una sola unidad. El "pequeño" el conjunto de datos pronto se vuelve muy grande a medida que agrega pruebas para diferentes escenarios. En cambio, las pruebas pueden insertar datos en la base de datos para configurar el accesorio de prueba.

Answer 2

"Prueba de modernización de aplicaciones heredadas", destaca:

1. Descripción general de alto nivel de cómo se crean las pruebas en AscentialTest

2. Formas de convertir los objetos heredados a la nueva plataforma Componentes de definición de objetos

3. Cómo garantizar que la versión modernizada de la aplicación produzca los mismos resultados

Para obtener más detalles sobre el uso de la prueba de la aplicación heredada, consulte aquí:

http: // application-management .cioreview.com / whitepaper / testing-legacy-application-modernization-wid-529.html