La mejor manera de probar una aplicación Delphi

Question

Tengo una aplicación Delphi que tiene muchas dependencias, y sería difícil refactorizarla para usar DUnit (es enorme), así que estaba pensando en usar algo como TestComplete de AutomatedQA para hacer las pruebas desde la interfaz de usuario front-end.

Mi problema principal es que una corrección de errores o una nueva característica a veces rompe código viejo que se probó previamente (manualmente) y se usó para funcionar.

He configurado la aplicación para utilizar los modificadores de línea de comandos para abrir un formulario específico que podría ser probado, y puedo crear un conjunto de valores y clics necesarios.

Pero tengo un par de preguntas antes de hacer nada drástico ... (y antes de comprar cualquier cosa)

1. ¿Merece la pena?
2. ¿Sería esta una buena manera de probar?
3. El resultado de la prueba debería estar en mi base de datos (Oracle), ¿hay alguna manera fácil en el testcomplete de verificar estos valores (campos múltiples en varias tablas)?
4. Necesitaría configurar una base de datos de prueba para hacer todas las pruebas automatizadas, ¿habría una manera fácil de automatizar el reajuste de la prueba db? Además de caer en cascada de usuario, crear usuario, ..., impdp.
5. ¿Hay alguna manera en el testcomplete de especificar los parámetros de la línea de comandos para un exe?
6. ¿Alguien tiene alguna experiencia similar.

Answer 1

Estoy en una situación similar. (Gran aplicación con muchas dependencias). Casi no hay pruebas automatizadas. Pero hay un gran deseo de solucionar este problema. Y es por eso que vamos a abordar algunos de los problemas con cada nuevo lanzamiento.

Estamos a punto de lanzar la primera versión del nuevo producto. Y los primeros signos son buenos. Pero fue mucho trabajo. Así que el próximo lanzamiento seguramente necesitamos alguna forma de automatizar el proceso de prueba. Es por eso que ya estoy presentando pruebas unitarias. Aunque debido a las dependencias, estas no son pruebas unitarias reales, pero tienes que comenzar en alguna parte.

cosas que hemos hecho:

• introducido un enfoque más orientado a objetos, porque una gran parte del código seguía siendo de procedimiento.
• Se movieron cosas entre archivos.
• Se eliminaron las dependencias cuando fue posible.

Pero hay mucho más en la lista de requisitos, asegurando suficiente trabajo para todo el equipo hasta la jubilación.

Y tal vez soy un poco extraño, pero limpiar el código puede ser divertido. La refactorización sin pruebas unitarias es una tarea peligrosa, especialmente si hay muchos efectos secundarios. Usamos programación de pares para evitar errores estúpidos. Y muchas sesiones de prueba. Pero al final tenemos un código más limpio, y la cantidad de nuevos errores introducidos fue extremadamente baja.

Ah, y asegúrese de saber que este es un proceso costoso. Lleva mucho tiempo. Y tienes que luchar contra la tendencia a abordar más de un problema en una fila.

Answer 2

No puedo responder todo, ya que nunca he usado testcomplete, pero puedo responder algunas de ellas.

1 - Sí. Las pruebas de regresión lo valen. Es bastante vergonzoso para usted como desarrollador cuando el cliente recurre a usted cuando ha roto algo que solía funcionar. Siempre es una buena idea asegurarse de que todo lo que solía funcionar todavía lo haga.

4 - Oracle tiene algo llamado Flashback que le permite crear un punto de restauración en la base de datos. Después de que hayas hecho las pruebas, puedes retroceder a este punto de restauración. Puede escribir scripts para usarlo también, FLASHBACK DATABASE TO TIMESTAMP (FEB-12-2009, 00:00:00);, etc.

Answer 3

Sugiero que planee usar tanto DUnit como TestComplete, ya que cada uno de ellos tiene un objetivo diferente.

DUnit es ideal para pruebas unitarias, pero es difícil de usar para las pruebas generales de aplicaciones y UI.

TestComplete es uno de los pocos productos de prueba automatizados que en realidad tiene soporte para Delphi, y nuestro ingeniero de QA me dice que su soporte es muy bueno.

Tenga en cuenta que la configuración de pruebas automatizadas es un trabajo grande y que requiere mucho tiempo. Si aplica rigurosamente las pruebas unitarias y las pruebas UI mejoradas, podría terminar fácilmente con más código de prueba que código de producción.

Con una aplicación grande (existente) se encuentra en una situación difícil con respecto a la implementación de pruebas automatizadas.

Mi recomendación es configurar las Pruebas unitarias primero, junto con un servidor automatizado de compilación. Cada vez que alguien verifica cualquier cosa en el control de la fuente, las pruebas unitarias se ejecutan automáticamente. NO intente configurar pruebas unitarias para todo: es un esfuerzo demasiado grande para una aplicación existente. Solo recuerde crear pruebas unitarias cada vez que agregue nuevas funcionalidades, y siempre que esté a punto de hacer cambios. También sugiero encarecidamente que cada vez que se informa un error, cree una prueba unitaria que reproduzca el error ANTES de solucionarlo.

Answer 4

Una forma de introducir una prueba unitaria en una aplicación (antigua) podría ser tener una "base de datos de inicio" (como la función "Flashback" descrita por Rich Adams). El programa som unittest usa DUnit para controlar la GUI. Se la "Prueba GUI con DUnit" en http://delphixtreme.com/wordpress/?p=181

Cada vez que se inicia la prueba, se restaura en "Iniciar base de datos", porque se puede usar un conjunto de datos conocidos.

Answer 5

Estamos considerando el uso de VMWare para aislar algunas de nuestras pruebas.

Puede comenzar desde una instantánea guardada, para que siempre tenga un entorno coherente y el estado de la base de datos local.

Las acciones de VMWare se pueden programar, por lo que puede instalar automáticamente su última compilación desde una ubicación de red, iniciar las pruebas y cerrarse después.

Answer 6

1. ¿Valdrá la pena?

Probably. Configurar y mantener las pruebas puede ser un gran trabajo, pero cuando las tiene, las pruebas se pueden ejecutar de manera fácil y consistente. Si su proyecto está evolucionando, algún tipo de conjunto de pruebas es muy útil.

2. ¿Sería esta una buena manera de probar?

Yo diría que el correcto DUnit test suite es mejor primer paso. Sin embargo, si tiene una gran base de código que no está diseñada para realizar pruebas, la configuración de pruebas funcionales es incluso más dolorosa que la configuración de pruebas GUI.

3. El resultado de la prueba debería en mi base de datos (Oracle), ¿hay una forma fácil forma en TestComplete para comprobar estos valores (varios campos en varias tablas)?

TestComplete tiene interfaz ADO y BDE. O puede usar la interfaz OLE en VBScript para acceder a todo lo que está disponible.

5. ¿Hay alguna manera en TestComplete para especificar los parámetros de línea de comandos para un exe?

Sí.

Answer 7

que tendría que configurar una base de datos de prueba para hacer todo el pruebas automatizadas, ¿habría una manera fácil de automatizar la re-establecimiento de la prueba db?

Transacciones de uso: realice una reversión cuando finalice la prueba. Esto debería revertir todo al estado inicial.

Lectura recomendada:

http://xunitpatterns.com/