2012-01-08 14 views
8

Recientemente se ha agregado un nuevo concepto de Theories a JUnit (desde v4.4).¿Por qué JUnit ejecuta casos de prueba para teoría solo hasta la primera falla?

En pocas palabras, usted puede marcar su método de prueba con @Theory anotación (en lugar de @Test), que su método de prueba parametrizada y declarar una matriz de parámetros, marcado con @DataPoints anotación en algún lugar de la misma clase.

JUnit se ejecutará secuencialmente sus parámetros de paso del método de prueba parametrizados recuperados de @DataPoints uno tras otro. Pero solo hasta que falle la primera invocación (por cualquier motivo).

El concepto parece ser muy similar al @DataProviders de TestNG, pero cuando utilizamos proveedores de datos, todos los escenarios se ejecutan a pesar de los resultados de ejecución. Y es útil porque puede ver cuántos trabajos/no funcionan y puede arreglar su programa de manera más efectiva.

Entonces, me pregunto cuál es la razón para no ejecutar @Theory -metodo marcado para cada @DataPoint? (Al parecer, no es tan difícil de heredar de corredor Teorías y hacer un corredor costumbre que no hará caso de fallas, pero ¿por qué no tenemos tal comportamiento fuera de la caja?)

UPD: He creado una tolerancia a fallos versión del corredor Teorías y lo puso a disposición para un acceso público: https://github.com/rgorodischer/fault-tolerant-theories

con el fin de compararla con las teorías estándar corredor corrida StandardTheoriesBehaviorDemo continuación FaultTolerantTheoriesBehaviorDemo que se sometan a src/test/... carpeta.

Respuesta

1

AFAIK, la idea es la misma que con afirma, el primer fallo se detiene la prueba. Esta es la diferencia entre las teorías parametrizadas &.

parametrizada toma un conjunto de puntos de datos y se ejecuta un conjunto de métodos de ensayo con cada uno de ellos. Las teorías hacen lo mismo, pero fallan cuando falla la primera afirmación.

intente buscar en Parameterized. Tal vez proporciona lo que quieres.

+0

vea el upd (pensé que podría encontrarlo interesante). – Roman

3

informes fallas múltiples en una sola prueba es generalmente una señal de que la prueba hace demasiado, en comparación con lo que es una prueba de la unidad debe hacer. Por lo general, esto significa ya sea que la prueba es realmente una prueba funcional /aceptación/cliente o, si se trata de una prueba de unidad, entonces es demasiado grande una prueba de unidad.

JUnit está diseñado para funcionar mejor con una serie de pequeñas pruebas. Es ejecuta cada prueba dentro de una instancia separada de la clase de prueba. Es informa falla en cada prueba. El código de configuración compartida es más natural cuando se comparte entre las pruebas. Esta es una decisión de diseño que impregna JUnit, y cuando decide informar múltiples fallas por prueba, comienza a luchar contra JUnit. Esto no es recomendado

pruebas largas son un olor diseño e indican la probabilidad de un diseño problema. A Kent Beck le gusta decir en este caso que "hay una oportunidad de aprender algo sobre su diseño."Nos gustaría ver un lenguaje de patrones a desarrollar en torno a estos problemas, pero aún no ha sido escrito Fuente:. http://junit.sourceforge.net/doc/faq/faq.htm#tests_12

Ignorar errores de aserción también se puede utilizar una regla de colector de error JUnit:

la regla ErrorCollector permite la ejecución de una prueba para continuar después el primer problema se encuentra (por ejemplo, para recoger todas las incorrectas filas de una tabla, e informar a todos a la vez)

Por ejemplo, puede escribir una prueba como esta.

public static class UsesErrorCollectorTwice { 
    @Rule 
    public ErrorCollector collector= new ErrorCollector(); 

    @Test 
    public void example() { 
    String x = [..] 
    collector.checkThat(x, not(containsString("a"))); 
    collector.checkThat(y, containsString("b"));    
    } 
} 

El colector de errores utiliza Hamcrest Matchers. Dependiendo de tus preferencias, esto es positivo o no.

0

A La teoría es incorrecta si una sola prueba es incorrecta, de acuerdo con la definición de Teoría. Si sus casos de prueba no siguen esta regla, sería incorrecto llamarlos una "Teoría".

+0

en mi humilde opinión, para fines de ingeniería no es muy útil. Después de ejecutar las pruebas, quiere saber todo lo posible sobre la corrección de su sistema. De nuevo, no veo nada malo en saber, en cuál y en cuántos casos la teoría es incorrecta. Es mucho mejor que saber simplemente que la teoría es incorrecta sin ningún detalle. – Roman

+0

Se supone que escribirá pequeñas unidades de prueba, cada una de las cuales está probando su aplicación desde un solo lado. A veces este control se realiza mejor como una teoría. ** No puede ** ser de bajo uso para ningún propósito, porque se basa en el principio básico de la lógica práctica. Si le parece que es malo para usar en algún tema en un 99%, significa que tiene algunos problemas para comprender el tema. – Gangnus

Cuestiones relacionadas