Un problema obvio con el uso de afirmar

Las pruebas unitarias son una parte importante de cualquier proyecto lo suficientemente grande. Quiero compartir con ustedes una pequeña historia de detectives relacionada con su caída en masa no obvia.

Comienza con el hecho de que, como resultado de un cierto compromiso inofensivo, alrededor de 150 pruebas cayeron en el proyecto, mientras que el conjunto de pruebas de caída no fue estable. Las pruebas no estaban interconectadas, las pruebas se realizaron secuencialmente. La base de datos h2 en memoria se utiliza como fuente de datos para las pruebas. La caída de la gran mayoría de estas 150 pruebas estuvo acompañada por un error en el registro: "No se puede obtener una conexión, error de agrupación Tiempo de espera en espera de objeto inactivo". Debe decirse que el tamaño del grupo de conexiones al realizar pruebas en el proyecto es 1.

Una pequeña digresión lírica: en el código del proyecto, la transacción se desconecta del flujo periódicamente, luego el código se ejecuta en una transacción separada y, finalmente, la transacción se vincula. Para tales casos, se ha escrito una clase auxiliar, cuyo uso se parece a esto:

TransactionRunner.run(dbDataManager(), new MethodTransaction() { @Override public ExecutionResult runInTransaction() throws Exception { // ,       return result; } ); 

Como resultado del análisis, se reveló que el error comienza a aparecer después de una prueba fallida que contiene una llamada de código en una transacción:

 TransactionRunner.run(dbDataManager(), new MethodTransaction() { @Override public ExecutionResult runInTransaction() throws Exception { // ...   // assert   assert( 1, result.getSomeNotEqualOneIntValue() ); return result; } ); 

Eche un vistazo dentro de la clase TransactionRunner, una llamada al método conduce al siguiente código:

 protected ExecutionResult run() throws CommonException { Transaction outerTr = getThreadTransaction(); bindThreadTransaction(null); try { beginTransaction(); try { setResult(transactionCode.runInTransaction()); } catch (Exception e) { dbDataManager().rollbackTransaction(); if (transaction.onException(this, e)) throw e; } dbDataManager().commitTransaction(); return getResult(); } catch (Exception e) { throw ExceptionUtil.createCommonException(e); } finally { bindThreadTransaction(outerTr); } } 

Entonces, ¿cuál es el problema aquí? Y el problema es que el AssertionError que surge como resultado de la ejecución del código de prueba no se hereda de Exception, lo que significa que la transacción anidada no se revierte ni se confirma. Dado que el tamaño de la agrupación de conexiones es igual a uno, obtenemos el mismo error "No se puede obtener una conexión, error de agrupación Se agotó el tiempo de espera del objeto inactivo" al intentar obtener el objeto de conexión mediante pruebas posteriores.

Moraleja: es necesario colocar las afirmaciones en las pruebas con precaución, y en el caso de fallas no obvias y, en particular, masivas, una de las soluciones es verificar si el manejo de excepciones tiene en cuenta los objetos que no se heredan de Exception.

El caso me pareció digno de arreglo, tal vez esta experiencia sea útil para alguien.