afirmar frente a afirmaciones de JUnit

85

Hoy vi un caso de prueba de JUnit con una aserción de Java en lugar de las aserciones de JUnit. ¿Hay ventajas o desventajas significativas para preferir una sobre la otra?

— Robert
fuente

Hay diferencias absolutamente fácticas entre las aserciones de JUnit y la palabra clave 'assert' de Java. Esta no es una pregunta basada en opiniones.

— Thomas W

95

En JUnit4, la excepción (en realidad Error) lanzada por una assertaserción de JUnit es la misma que el error arrojado por la palabra clave java (AssertionError), por lo que es exactamente igual assertTruey diferente al seguimiento de la pila, no podría notar la diferencia.

Dicho esto, las afirmaciones tienen que ejecutarse con un indicador especial en la JVM, lo que hace que muchas pruebas parezcan pasar solo porque alguien olvidó configurar el sistema con ese indicador cuando se ejecutaron las pruebas de JUnit, lo que no es bueno.

En general, debido a esto, yo diría que usar JUnit assertTruees la mejor práctica, porque garantiza que se ejecute la prueba, asegura la consistencia (a veces usa assertThatu otras afirmaciones que no son una palabra clave de Java) y si el comportamiento de JUnit afirma debería cambiar en el futuro (como conectarse a algún tipo de filtro u otra función futura de JUnit) su código podrá aprovechar eso.

El propósito real de la palabra clave assert en Java es poder desactivarla sin penalización en tiempo de ejecución. Eso no se aplica a las pruebas unitarias.

— Yishai
fuente

26

Prefiero las aserciones de JUnit ya que ofrecen una API más rica que la assertdeclaración incorporada y, lo que es más importante, no necesitan habilitarse explícitamente a diferencia de lo assertque requiere el -eaargumento JVM.

— Adamski
fuente

1

-easiempre está habilitado mvn test, no es necesario -ea. Api más rico, buena captura. A veces creo que la API se usa incorrectamente en la prueba porque no es parte de la aplicación (a en api), prefiero llamarla solo métodos más ricos.

— Grim

19

Cuando una prueba falla, obtienes más información.

assertEquals(1, 2); resultados en java.lang.AssertionError: expected:<1> but was:<2>

vs

assert(1 == 2); resultados en java.lang.AssertionError

puede obtener aún más información si agrega el argumento del mensaje a assertEquals

— estrellado
fuente

9

prueba assert 1==2: "1 is not 2";.

— Grim

@PeterRader Prueba la palabra clave assert cuando -ea no está habilitado. O mejor aún, use aserciones JUnit que siempre funcionan.

— Thomas W

1

@ThomasW cuando -ea no está habilitado, no es una prueba. Las aseveraciones de JUnit no siempre funcionan, solo funcionan si decides usar JUnit, que es un marco, y en el caso de maven, una dependencia de maven, una dependencia de maven que debe estar solo en el alcance de prueba. Tenemos dos caras aquí: ¿Qué prefieres? 1er lado : use un marco, como una dependencia solo en el alcance de prueba, que debe descargarse, que eclipse le permite usar en clases que no están en la carpeta src / main-folder pero que no se compilan allí porque maven tiene junit solo en prueba- alcance o 2do lado : use el material incorporado.

— Grim

1

@PeterRader Esta pregunta trata sobre los casos de prueba de JUnit. En ese contexto, debe usarse JUnit o una clase de aserción similar, porque siempre están habilitadas. Personalmente, me sorprendió que la palabra clave Java 'assert' no estuviera habilitada en el pasado, y no creo que las afirmaciones poco confiables tengan un lugar en el código de prueba.

— Thomas W

En el contexto separado de las afirmaciones en el código de características, importante para la práctica de programación sólida, aunque en realidad no es el tema de la pregunta, tanto Spring como Google Guava tienen clases de aserción que siempre están habilitadas. Recomiendo el uso generoso de estos como condiciones previas de parámetros y estados para garantizar la corrección. Más allá de eso, en áreas críticas para el rendimiento, puede haber un área pequeña donde Java assertpuede ser preferible, para verificaciones de corrección que afectarían el rendimiento y, por lo tanto, es mejor desactivarlas de forma predeterminada. Sin embargo, mi experiencia es que la mayoría de las afirmaciones deben estar siempre activas.

— Thomas W

8

Yo diría que use JUnit asserts en casos de prueba y use Java's assert en el código. En otras palabras, el código real nunca tendrá dependencias JUnit, como es obvio, y si es una prueba, debería usar las variaciones JUnit del mismo, nunca la aserción.

— Bruno D. Rodrigues
fuente

0

Yo diría que si está usando JUnit, debe usar las aserciones de JUnit. assertTrue()es básicamente lo mismo que assert, De lo contrario, ¿por qué usar JUnit?

— CheesePls
fuente

4

Usaría JUnit para el marco de ejecución de prueba. Las afirmaciones son realmente una pequeña parte del valor que JUnit le brinda. JUnit sin Assertrequeriría más texto estándar. assertsin JUnit requeriría que escribieras un marco completo.

— Yishai

1

Estaba más diciendo que si vas a usar la herramienta, USE LA HERRAMIENTA. Las declaraciones de aserción antiguas y regulares parecen un poco tontas en los casos de prueba de JUnit. En mi opinión, pertenecen al código real.

— CheesePls

1

@CheesePls "declaraciones de aserción antiguas regulares" son de hecho más recientes de lo que afirma JUnit.

— dolmen

0

Es posible que esto no se aplique si usa exclusivamente cosas brillantes y nuevas, pero assert no se introdujo en Java hasta 1.4SE. Por lo tanto, si debe trabajar en un entorno con tecnología más antigua, puede inclinarse hacia JUnit por razones de compatibilidad.

— Dan Coates
fuente