Del curso: Domina Java: Test unitarios (JUnit)
Los métodos assertTrue() y assertFalse() - Tutorial de Java
Del curso: Domina Java: Test unitarios (JUnit)
Los métodos assertTrue() y assertFalse()
Ahora vamos con dos métodos que parecen muy tontos pero tienen su uso. Uso que no me acaba de convencer, ahora veremos por qué. Me refiero a assertTrue y assertFalse. Bueno, me centro en uno. El otro funciona igual, pero justo para los valores contrarios. Empecemos con mi primera afirmación; test1, assertTrue(true). Menuda obviedad. Pues claro que true es true, efectivamente. Pero la gracia ahí está en pasarle un booleano que hemos obtenido al hacer algo, algún booleano que tengamos por ahí. Aunque es verdad que assertTrue(true) lo he usado alguna vez como para decir que quiero que pase por esa línea, aunque no, no tiene demasiado sentido. test2, vamos con un ejemplo con más sentido. Muchas veces, el assertEquals no me vale, si quiero comprobar que el resultado es positivo o par o que un string contiene algo, tiene un tamaño dentro de un rango o empieza por mayúsculas, en fin, un montón de comprobaciones que podemos hacer sobre los resultados para las que tengamos un método que devuelve un booleano, pero no existe ningún assert que lo compruebe. Para eso, hacemos assertTrue o assertFalse sobre la condición, el predicado que nos interesa. ¿3 es mayor que 0 o hola lleva h? Genial, pero también he dicho que no me acaba de convencer. ¿Sabes por qué? Fíjate en el test3. Vamos a ejecutarlo, por cierto. Si compruebo si ola, las del mar, lleva h, no la lleva. Va a fallar. Veamos el mensaje. Esperaba cierto, pero era falso. ¡Ah, qué rabia me da! Esperaba cierto, pero era falso. No me dice nada. Esto, metido en un montón de código y de asserts, hace una locura descubrir qué valor malo he recibido. Me encantaría que dijera que ola no contiene h, que me mostrará los valores sobre los que se hace la comprobación, pero claro, aasertTrue no puede saberlo. Hagamos un cuarto test para ver qué es eso del BooleanSupplier que también pueden recibir estos métodos. Es la forma que tenemos de poder utilizar expresiones lambda en estos test. Imaginemos un método que nos comprueba si un número es positivo. Llamamos assertTrue llamando a ese método con x, que vale 3. Y esto debería dar cierto. Bien, pues si queremos hacer más o menos lo mismo, pero sin tener que crearnos el método, podemos hacerlo con una expresión lambda, como en el ejemplo de esPar; esPar no es un booleano en sí, es algo, una función, que nos devolverá un booleano. Como 3 no es par, nuestro test para que esto funcione debería ser un assertFalse.
Contenido
-
-
-
(Bloqueado)
Sensibilización a los test unitarios1 min 34 s
-
(Bloqueado)
Introducción a JUnit4 min 9 s
-
(Bloqueado)
El método assertEquals()3 min 27 s
-
(Bloqueado)
El método assertEquals() para números decimales2 min 6 s
-
Los métodos assertTrue() y assertFalse()2 min 26 s
-
(Bloqueado)
El método fail()2 min 27 s
-
(Bloqueado)
Comprobando colecciones y arrays3 min 42 s
-
(Bloqueado)
Comprobando listas de Strings3 min 59 s
-
(Bloqueado)
Comprobando excepciones1 min 45 s
-
(Bloqueado)
Más métodos assert2 min 35 s
-
(Bloqueado)
Métodos @Before y @After3 min 29 s
-
(Bloqueado)
Comprobando la salida por consola1 min 54 s
-
(Bloqueado)
Simulando la entrada por teclado51 s
-
(Bloqueado)
Las pruebas parametrizadas3 min 9 s
-
La cobertura de test2 min 25 s
-
(Bloqueado)
Objetos maquetados2 min 10 s
-
(Bloqueado)
Introducción a Mockito4 min 4 s
-
(Bloqueado)
La integración continua1 min 50 s
-
(Bloqueado)
Qué no son los test unitarios1 min 57 s
-
(Bloqueado)
Evolución de JUnit2 min 9 s
-
(Bloqueado)
Diseño de pruebas: complejidad ciclomática3 min 8 s
-
(Bloqueado)
Diseño de pruebas: caminos independientes1 min 44 s
-
(Bloqueado)
Diseño de pruebas: la implementación1 min 12 s
-
(Bloqueado)