oracle delphi testing testcomplete

oracle - La mejor forma de probar una aplicación Delphi



testing testcomplete (7)

Estamos estudiando 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 un estado de base de datos local.

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

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 IU del front-end.

Mi problema principal es que una corrección de error 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 usar los modificadores de la línea de comandos para abrir un formulario específico que podría probarse, y puedo crear un conjunto de valores y hacer clic necesarios.

Pero tengo algunas preguntas antes de hacer algo drástico ... (y antes de comprar algo)

  1. ¿Vale la pena?
  2. ¿Esta sería 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 (múltiples campos en varias tablas)?
  4. Tendría que configurar una base de datos de prueba para hacer todas las pruebas automatizadas, ¿habría una manera fácil de automatizar el restablecimiento de la prueba db? Además de caer en cascada de usuario, crear usuario, ..., impdp.
  5. ¿Hay alguna manera en la prueba completa de especificar parámetros de línea de comandos para un exe?
  6. ¿Alguien tiene experiencias similares?

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. También puede escribir scripts para usarlo, FLASHBACK DATABASE TO TIMESTAMP (FEB-12-2009, 00:00:00); , etc.

Sugeriría que planees usar tanto DUnit como algo así como TestComplete, ya que cada uno de ellos tiene un propósito 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.

Sin embargo, 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 establecer Primero las Pruebas unitarias, junto con un servidor de compilación automatizado. 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.

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 prueba usando 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 conocido de datos.

  1. ¿Vale la pena?

Probablemente. 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.

  1. ¿Esta sería una buena manera de probar?

Yo diría que el mejor conjunto de pruebas DUnit es el 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.

  1. 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 (múltiples campos en múltiples tablas)?

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

  1. ¿Hay alguna manera en la prueba completa de especificar parámetros de línea de comandos para un exe?

Sí.

Tendría que configurar una base de datos de prueba para hacer todas las pruebas automatizadas, ¿habría una manera fácil de automatizar el restablecimiento de la prueba db?

Usar transacciones: realice una reversión cuando se complete la prueba. Esto debería revertir todo al estado inicial.

Lectura recomendada:

http://xunitpatterns.com/

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:

  • Introdujo un enfoque más OO, porque una gran parte del código todavía era de procedimiento.
  • Se movió cosas entre archivos.
  • Se eliminaron las dependencias siempre que sea 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.