2010-10-26 15 views
5

Me gustaría poder verificar si cada unidad de trabajo se realiza en su propia transacción o como parte de una sola transacción global.¿Es posible probar la transaccionalidad de un proceso?

Tengo un método (que se define usando la primavera y de hibernación), que es de la forma:

private void updateUser() { 
    updateSomething(); 
    updateSomethingElse(); 
} 

Esto se llama a partir de dos lugares, el sitio web cuando un usuario inicia sesión y un trabajo por lotes que circula diariamente . Para el contexto del servidor web, se ejecutará con una transacción creada por el servidor web. Para el trabajo por lotes, debe tener una transacción para cada usuario, de modo que si algo falla durante este método, la transacción se retrotrae. Así que tenemos dos métodos:

@Transactional(propagation=Propagation.REQUIRES_NEW) 
public void updateUserCreateNewTransaction() { 
    updateUser(); 
} 

@Transactional(propagation=Propagation.REQUIRED) 
public void updateUserWithExistingTransaction() { 
    updateUser(); 
} 

updateUserCreateNewTransaction() es llamado desde el trabajo por lotes, y updateUserWithExistingTransaction() desde el contexto del servidor web.

Esto funciona. Sin embargo, es muy importante que este comportamiento (del lote) no se modifique, por lo que deseo crear una prueba que pruebe este comportamiento. Si es posible, me gustaría hacer esto sin cambiar el código.

Así que algunas de las opciones abiertas para mí son:

  1. Count las transacciones abiertas en la base de datos durante la ejecución del lote trabajo.

  2. Cambie los datos de alguna manera secundaria para que al menos una actualización de usuario falle, en el método updateSomethingElse(), y verifique que updateSomething() para ese usuario no haya tenido lugar.

  3. Revisión de código.

1 es un método muy dependiente de la base de datos, y cómo puedo garantizar que hibernación no creará una transacción de todas formas ?. 2 parece mejor, pero es muy complejo de configurar. 3 no es realmente práctico porque tendremos que hacer uno para cada lanzamiento.

Entonces, ¿alguien tiene un método que me permita probar este código, preferiblemente a través de una prueba de sistema o prueba de integración?

Respuesta

2

Intentaría configurar una prueba en un arnés de prueba de unidad usando una memoria en HSQLDB y EasyMock (u otro marco de burla).

A continuación, podría tener el método updateSomething() realmente escribir a la base de datos HSQL pero el uso del marco simulacro para burlarse del método updateSomethingElse() y lanzar una RuntimeException de ese método. Una vez hecho esto, puede realizar una consulta en contra de HSQLDB para verificar que las cosas updateSomething() se hayan revertido.

Requerirá un poco de instalación de plomería para HSQLDB y el administrador de transacciones, pero una vez hecho esto, tiene una prueba sin dependencias externas que se puede volver a ejecutar siempre que lo desee.

Cuestiones relacionadas