procedimientos - ¿Cómo lograr pruebas de aislamiento de pruebas de Oracle PL/SQL?

procedure oracle ejemplos

Question

En los proyectos Java, las pruebas de JUnit realizan una configuración, una prueba y un desmontaje. Incluso cuando se burla de una base de datos real con una base de datos en memoria, normalmente se deshace de la transacción o se extrae la base de datos de la memoria y se vuelve a crear entre cada prueba. Esto le proporciona aislamiento de prueba, ya que una prueba no deja artefactos en un entorno que podría afectar la próxima prueba. Cada prueba comienza en un estado conocido y no puede sangrar en otra.

Ahora tengo una compilación de db Oracle que crea 1100 tablas y 400K de código, muchos paquetes pl / sql. Me gustaría no solo probar la instalación de la base de datos (completa - crear desde cero, parcial - actualizar desde una base de datos anterior, etc.) y asegurarme de que todas las tablas y otros objetos estén en el estado que espero después de la instalación, sino TAMBIÉN ejecutar pruebas en el pl / sql (no estoy seguro de cómo haría exactamente lo primero: ¿sugerencias?).

Me gustaría que todo esto se ejecute desde Jenkins para CI para que los errores de desarrollo se detecten mediante pruebas de regresión.

En primer lugar, tengo que usar una versión empresarial en lugar de XE porque XE no es compatible con los SP de Java y una dependencia de Oracle Web Flow. Incluso si elimino esas dependencias, la compilación suele tardar 1,5 horas en cargarse (compilación completa).

Entonces, ¿cómo lograr el aislamiento de prueba en este entorno? ¿Usar las transacciones para cada prueba y revertirlas? OK, ¿qué pasa con los procedimientos pl / sql que tienen comprometidos en ellos?

Pensé en la copia de seguridad y la recuperación para restablecer la base de datos después de cada prueba, o volver a crear la base de datos completa entre cada prueba (demasiado drástica). Ambas no son prácticas ya que lleva más de una hora instalarlas. Hacerlo para cada prueba es excesivo y demente.

¿Hay una manera de dibujar una línea en la arena en el esquema (s) db y luego volver a enrollarla a ese punto en el tiempo? Sorta le gusta una gran característica ''deshacer''. Algo además de expdp / impdp o rman. Tal vez todo el enfoque está apagado. Sugerencias? ¿Cómo han hecho esto otros?

Para CI o una ventana de actualización de producción pequeña, el conjunto de pruebas de whold debe ejecutarse en un tiempo razonable (30 minutos sería ideal).

¿Hay productos que podrían ayudar a lograr esta capacidad de "deshacer"?

Answer 1

1.5 horas parece mucho tiempo para 1100 tablas y 400K de código. Obviamente, no conozco los detalles de su entorno, pero según mi experiencia, apuesto a que puede reducir eso de 5 a 10 minutos. Aquí están los dos problemas principales del script de instalación que he visto con Oracle:

1. Las operaciones se rompen en pequeños pedazos.

Cuantos más pasos tengas, más sobrecarga habrá. Por ejemplo, desea consolidar código como este lo más posible:

Reemplazar:

create table x(a number, b number, c number);
alter table x modify a not null;
alter table x modify b not null;
alter table x modify c not null;

Con:

create table x(a number not null, b number not null, c number not null);

Reemplazar:

insert into x values (1,2,3);
insert into x values (4,5,6);
insert into x values (7,8,9);

Con:

insert into x
select 1,2,3 from dual union all
select 4,5,6 from dual union all
select 7,8,9 from dual;

Esto es especialmente cierto si ejecuta su script y su base de datos en diferentes ubicaciones. Ese pequeño retraso en la red comienza a importar cuando lo multiplicas por 10,000. Cada herramienta de Oracle SQL que conozco enviará un comando a la vez.

2. Los desarrolladores tienen que compartir una base de datos.

Esta es más una solución de proceso a largo plazo que una solución técnica, pero tiene que empezar alguna vez. La mayoría de los lugares que usan Oracle solo lo tienen instalado en unos pocos servidores. Entonces se convierte en un recurso escaso que debe ser manejado cuidadosamente. La gente se pelea por eso, los roles no están claros y las cosas no se arreglan.

Si ese es su entorno, detenga la locura e instale Oracle en cada computadora portátil ahora mismo. Gaste unos cuantos cientos de dólares y ofrezca a todos una edición personal (que tiene las mismas características que la Edición Enterprise). Ofrezca a todos las herramientas que necesitan y la mejora continua eventualmente solucionará sus problemas.

Además, para un esquema "deshacer", es posible que desee buscar en espacios de tabla transportables. Nunca lo he usado, pero supuestamente es una forma mucho más rápida de instalar un sistema: solo copie y pegue archivos en lugar de importarlos. De manera similar, quizás algún tipo de virtualización pueda ayudar: crear una instantánea del sistema operativo y la base de datos.

Answer 2

Aunque Oracle Flashback es una característica Enterprise Edition, la tecnología en la que se basa está disponible en todas las ediciones, a saber, Oracle Log Miner:

http://docs.oracle.com/cd/B28359_01/server.111/b28319/logminer.htm#i1016535

Me interesaría saber si alguien ha usado esto para proporcionar aislamiento de prueba para pruebas funcionales, es decir, consultar v $ LOGMNR_CONTENTS para obtener una lista de declaraciones UNDO desde un punto de tiempo correspondiente al comienzo de la prueba.

La base de datos debe estar en modo de archivo y, en el caso de prueba de Junit, un método anotado con

@Startup 

llamaría DBMS_LOGMNR.START_LOGMNR. La prueba se ejecutaría y luego en un método anotado con

@Teardown

sería consultar v $ LOGMNR_CONTENTS para encontrar la lista de sentencias UNDO. Estos entonces serían ejecutados vía JDBC. De hecho, la consulta y la ejecución de las declaraciones UNDO podrían extraerse en un procedimiento almacenado PLSQL. La orden en que se ejecutan las declaraciones debería ser considerada.

Creo que esto tiene el beneficio que permite que la transacción se cometa, que es donde una gran cantidad de errores pueden aparecer en la integridad referencial, violaciones de la clave principal, etc.

Answer 3

En Oracle puede usar la tecnología Flashback para restaurar el servicio a un punto atrás en el tiempo.

http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/rcmflash.htm

Answer 4

Kevin McCormack publicó un artículo en The Server Labs Blog sobre pruebas de integración continua para PL / SQL utilizando Maven y Hudson. Échale un vistazo El ingrediente clave para el componente de prueba es el marco utPlsql de Steven Feuerstein , que es una implementación de los conceptos de JUnit en PL / SQL.

La necesidad de restablecer nuestros dispositivos de prueba es uno de los grandes problemas con las pruebas PL / SQL. Una cosa que ayuda es observar las buenas prácticas y evitar compromisos en los procedimientos almacenados: el control transaccional debe restringirse solo a las partes más externas de la pila de llamadas. Para aquellos programas que simplemente deben emitir confirmaciones (quizás implícitamente porque ejecutan DDL) siempre hay un dispositivo de prueba que emite sentencias DELETE. El manejo de la integridad relacional hace que sean bastante difíciles de codificar.

Un enfoque alternativo es utilizar Data Pump. Pareces descartar impdp pero Oracle también proporciona PL / SQL API para ello, DBMS_DATAPUMP . Lo sugiero aquí porque proporciona la capacidad de eliminar cualquier dato existente antes de ejecutar una importación. Así que podemos tener un conjunto de datos exportados como nuestro dispositivo de prueba; ejecutar un SetUp es una cuestión de ejecutar un trabajo de Data Pump. No es necesario hacer nada en TearDown, porque esa ordenación ocurre al inicio de la configuración.