61
Hoy vi un caso de prueba JUnit con una aserción java en lugar de las aserciones JUnit: ¿hay ventajas o desventajas significativas para preferir una sobre la otra?afirmar frente a las aserciones JUnit
A
Respuesta
78
En junit4 la excepción (en realidad un error) lanzada por un afirman JUnit es el mismo que el error que se produce por la palabra clave java assert (AssertionError), por lo que es exactamente el mismo que assertTrue y aparte de la traza de la pila no podías t di la diferencia.
Dicho esto, las afirmaciones tienen que ejecutarse con una bandera especial en la JVM, lo que hace que muchas pruebas parezcan pasar simplemente porque alguien olvidó configurar el sistema con esa bandera cuando se ejecutaron las pruebas JUnit, lo que no es bueno.
En general, debido a esto, yo diría que el uso de la JUnit assertTrue es la mejor práctica, ya que garantiza la prueba se ejecuta, asegura la consistencia (Algunas veces usa assertThat u otro afirma que no son una palabra clave de Java) y si el comportamiento de JUnit afirma que debería cambiar en el futuro (como enganchar en algún tipo de filtro u otra característica futura de JUnit) tu código podrá aprovechar eso.
El verdadero propósito de la palabra clave assert en java es poder desactivarlo sin penalización de tiempo de ejecución. Eso no se aplica a las pruebas unitarias.
24
prefiero afirmaciones JUnit, ya que ofrecen una API más rica que la incorporada en assert declaración y, lo más importante no es necesario que se habilite explícitamente a diferencia assert, lo que requiere el argumento -ea JVM.
+0
'-ea' siempre está habilitado en' mvn test', no es necesario '-ea'. Api más rica, buena captura. A veces creo que API se usa mal en la prueba porque no es parte de la aplicación (una en API), prefiero llamarlo métodos más ricos. –
0
Yo diría que si está usando JUnit debe usar las aserciones JUnit. assertTrue() es básicamente lo mismo que assert, De lo contrario, ¿por qué utilizar JUnit?
+2
Utilizaría JUnit para el marco de ejecución de prueba. Las aseveraciones son realmente una pequeña parte del valor que JUnit te brinda. JUnit sin 'Assert' requeriría más repetitivo. 'assert' sin JUnit requeriría que escribieras un framework completo. – Yishai
+0
Más bien dije que si vas a usar la herramienta, UTILIZA LA HERRAMIENTA. las afirmaciones de afirmación antiguas regulares parecen un poco tontas en los casos de prueba JUnit. Pertenecen con el código real en mi opinión. – CheesePls
+0
@CheesePls "declaraciones de afirmación antiguas normales" son, de hecho, más recientes de lo que afirma JUnit. – dolmen
0
Esto puede no aplicarse si utiliza exclusivamente material que es brillante y nuevo, 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 recurrir a JUnit por razones de compatibilidad.
11
Cuando falla una prueba, obtiene 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
, usted puede obtener más información si se agrega el argumento mensaje a assertEquals
+2
intente 'assert 1 == 2:" 1 no es 2 ";'. –
+0
@PeterRader Pruebe la palabra clave assert cuando -ea no está habilitado. O mejor aún, use aserciones JUnit que siempre funcionan. –
+0
@ThomasW cuando -ea no está habilitado, no es una prueba. Las asambleas de JUnit no siempre funcionan, solo funcionan si decides usar JUnit lo que es un framework, y en caso de una dependencia de maven a maven, una dependencia de maven que debe estar solo en el alcance de prueba. Tenemos dos lados aquí: ¿qué prefieres? ** 1st Side **: Use un framework, como una dependencia en el ámbito de prueba solamente, que se debe descargar, ese eclipse le permite usar en clases que no están en la carpeta src/main pero que no compilará allí porque maven junit solo en el alcance de la prueba o ** 2do lado **: use las cosas incorporadas. –
5
yo diría que el uso de JUnit afirma en casos de prueba, y usa la afirmación de java en el código. En otras palabras, el código real nunca tendrá dependencias JUnit, como obvio, y si es una prueba, debe usar las variaciones JUnit de ella, nunca la afirmación.
Cuestiones relacionadas
- 1. Afirmar sobre una lista en Junit
- 2. Eclipse: habilite las aserciones
- 3. ¿Las aserciones siempre son malas?
- 4. ¿Utiliza aserciones?
- 5. ¿Cuándo usar un marco de prueba de unidad (frente a usar solo aserciones)?
- 6. Java - Programando con aserciones preguntas
- 7. librerías de aserciones independientes?
- 8. Prueba unitaria sin aserciones
- 9. Compilación sin aserciones
- 10. NUnit frente a MbUnit frente a MSTest frente a xUnit.net
- 11. Mejorando el código lambda OCaml genera para las aserciones
- 12. Prestaciones de estructuras frente a las clases
- 13. Objective-C frente a las declaraciones #imports
- 14. ¿Cómo afirmar algo en tiempo de compilación en Java?
- 15. iterador frente a referencia frente a puntero
- 16. Extraño afirmar que no funciona en las variables lógicas y de bool
- 17. SQL: impone cardinalidad con aserciones
- 18. Las diferencias entre JUnit 3 y JUnit 4
- 19. Personalizar C++ afirmar macro
- 20. Alternativas a JUnit
- 21. Agregar mensaje para afirmar
- 22. ¿Cómo ignorar las llamadas a métodos inesperados en JUnit/easymock?
- 23. ¿Es posible "afirmar" en Puppet?
- 24. Página frente a extensión frente a segmento frente a espacio de tabla
- 25. Errores frente a la mejora frente a la nueva función
- 26. Terminología de persistencia de objetos: 'repositorio' frente a 'almacenar' frente a 'contexto' frente a 'retriever' vs. (...)
- 27. Metaetiqueta frente a robots.txt
- 28. Interceptar JUnit Assert functions
- 29. Aserciones de prueba para tuplas con flotadores
- 30. DateTime.Now frente a DateTime.UtcNow
Creo que esta pregunta debe reabrirse: la respuesta principal es extremadamente útil. – jakebeal
Existen diferencias absolutamente objetivas entre las aserciones JUnit y la palabra clave Java 'assert'. Esto no es en absoluto una pregunta basada en la opinión. –