Mejor manera de restablecer la base de datos de estado conocido entre las pruebas de integración FlexUnit4?

Question

Antecedentes:

Tengo una aplicación web Flex que se comunica con un back-end de Java a través de BlazeDS. El cliente Flex se compone de un módulo de flexión-cliente, el cual tiene las vistas y modelos de presentación y un módulo de flexión-servicio independiente que contiene los modelos (objetos de valor) y los objetos de servicio.

Estoy en el proceso de escribir las pruebas de integración asíncronos para RemoteObjects del módulo flexible servicio utilizando FlexUnit4. En algunas de las pruebas, modifico los datos de prueba y consulta de nuevo para ver si todo funciona (una técnica que se muestra aquí: http://saturnboy.com/2010/02/async-testing-with-flexunit4 )

Pregunta:

¿Cómo hago para restablecer la base de datos a un estado conocido antes de cada método de prueba FlexUnit4 (o cadena método de prueba)? En mis pruebas de integración de servidor Java, lo hice a través de una combinación de DBUnit y las transacciones de pruebas de la primavera - la cual rollback después de cada método de ensayo. Sin embargo, estos abarcan la integración FlexUnit múltiples peticiones y, por tanto múltiples transacciones.

A falta de implementación de un servicio de integración de la API de pruebas en el backend, ¿cómo se puede lograr esto. Sin duda, otros han topado con esto también? Preguntas similares se han preguntado antes ( Rollback base de datos después de integración (selenio) pruebas ) , pero sin respuestas satisfactorias.

Answer 1

Hay varias opciones:

1. Si utiliza secuencias para las claves principales: Después de la base de datos ha sido cargado con los datos de prueba, eliminar el generador de secuencias y sustituirlo por uno que comienza con -1 y una cuenta atrás. Después de la prueba, puede eliminar los objetos con una clave principal <0. pausas para las pruebas que modifican los datos existentes.

   Un enfoque similar es crear un usuario especial o, si tiene columnas de marca de hora created, a continuación, los datos iniciales deben estar antes de una fecha en el pasado. Eso tiene índices adicionales, sin embargo.

2. Usar una base de datos en el servidor que puede ser borrado rápidamente ( H2 , por ejemplo). Añadir una API de servicio que se puede llamar desde el cliente para restablecer la base de datos.

3. Añadir deshacer a su aplicación web. Eso es todo un esfuerzo, pero una característica muy fresco.

4. Usar una base de datos que permite retroceder en el tiempo con un solo comando, como Lotus Notes.

5. No utilice una base de datos en absoluto. En vez escribir un servidor proxy que responderá a la entrada correcta con la salida correcta. Añadir un poco de código a su servidor real para escribir los datos intercambiados en un archivo y crear sus pruebas de ello.

   casos

   o la prueba de escritura que se ejecutan en el servidor real y que crean estos archivos. Eso permitirá hacer un seguimiento de los archivos que el cambio al modificar el código en el servidor o cliente.

   En el servidor, pruebas de escritura que garanticen que se va a hacer las modificaciones correcta DB.

6. Al igual que en "ninguna base de datos en absoluto", ocultar todo el código que accede a la base de datos en una capa y utilizar DB interfaces para acceder a ella. Esto le permite escribir una capa maqueta que se comporta como la base de datos real, pero que guarda los datos en la memoria. Suena simple, pero es por lo general una gran cantidad de trabajo.

Answer 2

Dependiendo del tamaño de su base de datos de prueba, se podría automatizar las copias de seguridad limpias / restauraciones que le da el ambiente exacto que tenía en cada prueba.

He dicho enfoque en el de mis proyectos actuales (plataforma diferente) y también guiones cambio de esquema de datos de prueba con el mismo enfoque.

Answer 3

Estoy deshidratado (mi favorito excusa para falencias). Lo siento si esta respuesta es demasiado cerca de la "integración API de servicio de pruebas en el backend" respuesta que usted no quería.

El equipo que 'hace mucho tiempo' de puesta a punto FlexUnit tomado decisiones y soluciones creadas basadas en nuestra arquitectura, algunas de las cuales sólo se aplicaría a nuestra infraestructura. Cosas para considerar: 1) todos nuestros métodos de back-end regresar la misma clase asignada a distancia. 2) la mayoría de todos los métodos tienen un método abstracto que decir que el método (o no) ejecutar un "begin transaction" al principio del procedimiento y una "transacción de confirmación" al final (no estoy seguro de que su trozo db) .

Esto último no es probablemente la solución más orientada a objetos, pero aquí es lo que hace una llamada de prueba de unidad asíncrona: Cada unidad de prueba llama al mismo método de envoltura, y pasamos en el nombre del método / paquete de la configuración regional, además de la [...] args. Un beginTransaction está hecho. El método se llama, pasando una falsa al método para pruebas de unidad de Fe (ignorar las líneas BeginTransaction y CommitTransaction), todo se ejecuta y se genera la clase principal 'respuesta' y se devuelve al método de prueba de la unidad. A db-rollback se ejecuta y la respuesta se devuelve a la unidad de prueba.

Todas las pruebas unitarias se basan en transacciones rodar-back. Yo no podría decir de los problemas que tenían al configurar que jive, pero esa es mi comprensión general de cómo funciona la schtuff.

Espero que ayude. Comprensible si no lo hace. La mejor de las suertes, --jeremy