Pruebas unitarias, puntos muertos y condiciones de carrera

Question

¿Alguna sugerencia sobre cómo escribir pruebas de unidad repetibles para el código que puede ser susceptible de bloqueos y condiciones de carrera?

En este momento me inclino por saltarme las pruebas unitarias y me estoy enfocando en las pruebas de estrés. El problema con eso es que puedes realizar una prueba de esfuerzo 5 veces y ver cinco resultados diferentes.

EDITAR: Sé que es probable que solo sea un sueño, pero si hubiera una manera de controlar los hilos individuales y hacer que ejecuten una instrucción a la vez, podría llegar a alguna parte.

Answer 1

Echa un vistazo a TypeMock Racer (está en Beta)

editar: en realidad Alpha

http://www.typemock.com/Typemock_software_development_tools.html

Answer 2

Por lo general, es posible forzar previsiones en condiciones de carrera y puntos muertos mediante el uso de ManualResetEvent para obtener cada hilo en el estado esperado antes de liberarlo, es decir, obtener el hilo A para tener el bloqueo y esperar. una señal ... obtener el subproceso B para solicitar el bloqueo, etc ...

Sin embargo, normalmente puede escribir una prueba de este tipo para investigar un error sospechoso, para probar cuándo se solucionó y que no vuelve a aparecer. Por lo general, diseñaría alrededor de las condiciones de la carrera (pero pruébelas de la mejor manera posible).

Answer 3

No creo que buscar condiciones de carrera realmente caiga en el ámbito de las pruebas unitarias. Más o menos, por definición, la única manera de probar las condiciones de carrera es pseudoaleatoria. A menos que esté dispuesto a esforzarse por demostrar formalmente la corrección de su estrategia de bloqueo, tendrá que hacer algunas pruebas de estrés.

Aún necesita escribir pruebas unitarias para verificar la corrección de los algoritmos, en lugar de la estrategia de bloqueo.

Cuando realice pruebas de estrés en código de subprocesos múltiples, querrá realizar pruebas en condiciones en las que tenga una CPU por subproceso, donde tenga múltiples subprocesos compartiendo la CPU y donde tenga más CPU que subprocesos (si es posible).

Answer 4

Puede escribir una clase de bloqueo que detecte posibles interbloqueos, mirando el orden de las operaciones de bloqueo. Hacemos esto teniendo un contexto de subproceso con el que se registran todos los bloqueos cuando se adquieren (se puede convertir en una opción solo DEBUG).

La idea es crear un gráfico donde los nodos representen bloqueos y un borde dirigido entre A y B significa que "el bloqueo A se mantenía cuando se adquirió el bloqueo B". Deje que su programa se ejecute con cargas normales, luego verifique los ciclos en el gráfico. Un ciclo significa que existe un potencial de interbloqueo incluso si su código no lo alcanzó.

Answer 5

No puedo pensar en una buena forma automatizada, pero lo más cerca que he estado de escribir una prueba de unidad que "expondría" un punto muerto fue mediante el uso de puntos de interrupción además de una prueba de unidad. Simplemente agregué algunas instrucciones sobre dónde agregar el punto de interrupción. Hay un cierto esfuerzo manual involucrado, pero con ellos siempre puedes exponer tu peor calendario de hilos de casos.

¿Quizás alguien ha descubierto una buena manera de automatizar este tipo de funcionalidad? Podría imaginarme ejecutando automáticamente el depurador, rompiendo un hilo en una línea específica, dejando que otro se ejecute hasta una condición específica, luego afirmando para la prueba de la unidad.

Answer 6

Anteriormente, he usado retrasos artificiales en el código que son activados por algunos parámetros en la solicitud. Por ejemplo, una solicitud le dice al servidor que demore la escritura entre dos escrituras y otra que las haga sin demora entre ellas.

A Mark Bessey escribe, esto solo es útil para crear repro, no para descubrir el problema.

Answer 7

¿Has probado Corensic Jinx ?