¿Cómo se agregan las pruebas para soporte multihilo?

Question

Tengo un servicio de Java que ahora se ejecutará en modo de proceso por lotes. El servicio admite múltiples subprocesos, por lo que para cada solicitud por lotes se dedicará un grupo de subprocesos para ejecutar el lote. La pregunta es ¿cómo pruebo esto? Tengo pruebas funcionales que pasan bajo la versión enhebrada del servicio, pero, de alguna manera, creo que debe haber una expresión idiomática para probar esto.

Answer 1

Realmente no hay una "buena" manera de hacer esto. Lo mejor que puedo sugerir es TestNG, que le permite anotar sus métodos de prueba y hacer que se ejecuten en n hilos al mismo tiempo. Por ejemplo:

@Test(invocationCount=10, threadPool=10) 
public void testSomethingConcurrently() { 
    ... 
} 

Mi conocimiento TestNG está oxidado en el mejor, pero que yo sepa que debe invocar el método testSomethingConcurrently 10 veces al mismo tiempo. Esta es una manera agradable y declarativa de ejecutar pruebas de subprocesos múltiples contra su código.

Por supuesto, puede hacer algo similar en JUnit al engendrar hilos manualmente en un bucle, pero eso es increíblemente feo y difícil de trabajar. Tuve que hacer esto una vez para un proyecto en el que estaba trabajando; Esas pruebas fueron una pesadilla para tratar, ya que sus fallas no siempre eran repetibles.

La prueba de concurrencia es difícil y propensa a la frustración, debido a su naturaleza no determinista. Esto es parte de por qué hay un gran impulso en estos días para utilizar mejores abstracciones de concurrencia, que son más fáciles de "razonar" y convencerse a uno mismo de lo correcto.

Answer 2

Estoy de acuerdo con Daniel, las pruebas de concurrencia son de hecho muy difíciles.

No tengo una solución para las pruebas de simultaneidad, pero le diré lo que hago cuando deseo probar el código que involucra el multi-threading. La mayoría de mis pruebas se realizan usando JUnit y JMock. Como JMock no funciona bien con varios hilos, utilizo una extensión para JMock que proporciona versiones sincrónicas de Executor y ScheduledExecutorService. Estos me permiten probar el código dirigido a ser ejecutado por múltiples hilos en un solo hilo, donde también puedo controlar el flujo de ejecución. Como dije antes, esto no prueba la concurrencia. Solo verifica el comportamiento de mi código de una sola vez, pero reduce la cantidad de errores que obtengo cuando cambio a los ejecutores de hilos múltiples.

De todos modos, recomiendo el uso de la nueva API de concurrencia de Java. Hace las cosas mucho más fáciles.

Answer 3

Por lo general, las cosas que reducen las aplicaciones multiproceso son cuestiones de tiempo. Sospecho que para poder realizar pruebas unitarias en todo el entorno multiproceso se necesitarían grandes cambios en la base del código para hacerlo.

Lo que bien puede hacer, sin embargo, es probar la implementación del grupo de subprocesos de forma aislada.

Al sustituir el cuerpo de los hilos con el código de prueba, debería ser capaz de construir sus condiciones patológicas de bloqueo y uso de recursos.

Luego, pruebe los elementos funcionales en un solo entorno con rosca, donde puede ignorar el tiempo.

Si bien esto no es perfecto, garantiza la repetibilidad, que es de gran importancia para las pruebas de su unidad.(Como se alude en la respuesta de Daniel Spiewak)

Answer 4

I utilizarse

@Test(threadPoolSize = 100, invocationCount = 100) 
    @DataProvider(parallel = true) 

ejecutados 100 hilos en paralelo 100 veces.