Organización de Tests en Funciones Separadas

Clase 6 de 24 • Curso Básico de Testing en Java

Resumen

La forma correcta de separar nuestras pruebas es realizar cada una en su propia función, además, el nombre de la función debe describir que estamos probando.

Para indicarle a JUnit que esperamos una excepción lo debemos hacer de la siguiente forma:

@Test(expected = IllegalArgumentException.class)

Jair Israel Avilés Eusebio

student•

El equivalente a la definicion del metodo repeat_string_negative_times en jUnit5 es de la siguiente manera, usando el metodo estatico asser throws, con 2 parametros.

La clase de la excepcion que se espera lanzar
Una declaracion de lambda funcion que es executable para ejecutar el metodo

@Test
public void repeat_string_negative_times() {
    assertThrows(IllegalArgumentException.class, () -> {
        StringUtil.repeat("hola", -1);
    });
}

Sanders Gutiérrez

student•

Y si quieres ir un paso más y controlar el mensaje de la exception en caso de que tengas una exception personalizada deberías hacer esto.

@Test
public void repeat_string_negative_times() {
    assertThrows(IllegalArgumentException.class, () -> {
        StringUtil.repeat("hola", -1);
    });

    String expected = "mensaje de la exception";

    assertEqual(expected, exception.getMessage());
}

juan carlos reyes granciano

student•

Gran aporte!!!

Cristhian Franco

student•

Se acabaron mis dias de probar cosas con System.out.println

Sanders Gutiérrez

student•

Jajajajaja, la primera vez que hice un test pensé lo mismo

Lina Marcela Patiño Pineda

student•

Hola Ferran, Cuál es el estandar que se debe usar para nombrar los métodos de los test, lo pregunto especialmente porque no estás usando la convención camel case.

Gracias.

Hipólito Morales

student•

Hola. Leyendo me topé con varias aproximaciones, entre ellas methodNameUnderTest_givenCondition_expectedBehavior y suena bien. Dejo los enlaces: https://hackernoon.com/unit-test-naming-given-when-then-java-84407911b858 https://dzone.com/articles/7-popular-unit-test-naming

Ferran Maylinch

teacher•

Gracias Hmorales!

Diría que no hay un estándar. Yo aconsejaría usar lo que más cómodo y claro te parezca. Si trabajas en equipo, acordad el estilo entre todos. :)

Respondí con más detalle en las preguntas generales del curso. Échale un vistazo.

Luis Enrique Rendon Cortez

student•

Se deben de colocar una método de test, por cada escenario que se desea probar, para mantener la independencia de cada prueba. El nombre los métodos debe ser muy descriptivo, para indicar que se espera del test.

Valida_cero_repeticiones
Valida_negativos Si se requiere probar el que un método valide una excepción en específico, se debe colocar esta excepción en el decorador del Test, indica que el método debe de lanzar la excepción de ese tipo. @Test(expected = IllegalArgumentsException::Class)

Antonio Jose Dos Ramos Lugo

student•

Una duda, porque utilizas :: en lugar de .class? :)

Sanders Gutiérrez

student•

jajajajajajaja, los dos puntos aquí @Test(expected = IllegalArgumentsException::Class) ha de ser porque vienes de PHP.

Francisco Imanol Suarez

student•

Dios era algo tan simple que en la Universidad lo hacían de una manera tan difícil.

Francisco Ruiz Lezcano

student•

Dejo mi aporte

class StringUtilTest {
    @Test
    void repeatStringPositiveTimes() {
        assertEquals("HelloHelloHelloHelloHello", StringUtil.repeat("Hello", 5));
    }

    @Test
    void repeatStringZeroTimes() {
        assertEquals("", StringUtil.repeat("Hello", 0));
    }

    @Test
    void repeatStringNegativeTimes() {
        assertThrows(IllegalArgumentException.class, () -> StringUtil.repeat("Hello", -10));
    }
}

Paul Cortes

student•

Notas: los nombres de los métodos de test deben de ser bastante descriptivos para saber que hacen específicamente y hacer varios para probar una misma funcionalidad para hacer la prueba de varios casos donde posiblemente podría fallar

Sebastián Ospino

student•

Para los que saben de streams y funciones en Java, una forma guapa de hacer el repeat es de la siguiente forma

public static BiFunction<String, Integer, String> reStr = (str, times) ->
            IntStream.range(0, times)
                    .mapToObj(i -> str)
                    .collect(Collectors.joining());

Samir Jimenez Vivas

student•

Y RECUERDEN AMIGOS ES UNA FUNCION POR TEST HASTA LA PROXIMA

Eduardo Gonzalez Esquivel

student•

He estado buscando en otras fuentes y aquí en el único lugar donde veo que separan el nombre de las palabras con "_". Esta es una buena practica?

Diego A de la Cruz Rojas

student•

Justo lo mismo me preguntaba y tambien lo de colocar la palabra "Should" o "Integration" al final del nombre de la clase test solo lo habia visto aqui.

Héctor jesus

student•

normalmente se usa el camelCase como buena practica por ejemplo: obtenerProductos()

Felipe de Jesús Galindo Aguilar

student•

¿Cómo saber cuantos test hacer?, puede que yo piense en algunos escenarios, pero que tal se me pasa alguno o hay un porcentaje de tests válidos.

Julio Jaramillo

student•

Hola @lipedeace_92, el numero de tests a realizar = numero de requerimientos que tengas, siempre haciendo un test negativo y uno positivo para que puedas probar lo que esperas y no esperas de tu requerimiento, siempre habla con el que te asigno tu requerimiento para hablen de posibles casos de uso y cubras los mas posibles, si ya tienes un código ya hecho puedes medir el coverage de tus tests y detectar que lineas no has probado. Espero haberte ayudado.

Sanders Gutiérrez

student•

Puedes los conceptos de programación de caja blanca, que son un tipo de prueba que intenta cubrir casos bordes al interior de tus métodos. Un ejemplo de eso podría ser el test que hizo el profesor para validar que times > 0 el cual lanza una excepción.

Otra forma que es la que yo suelo utilizar es, utilizar los escenarios o flujos normales de una historia de usuario.

Ejemplo:

Entonces si te basas en los criterios de validación tendrás mejores ideas para desarrollar tus tests.

JESUS ALMIRCAR CASTELLANOS

student•

⚡️Ir al resumen del curso

Leandro Molina

student•

Use Junit5 y asi me anduvo, en la clase test lo deje asi:

    @Test
    public void repetirNumerosNegativos(){
        Exception exception = Assertions.<IllegalArgumentException>assertThrows(IllegalArgumentException.class, () -> StringUtil.repetir("hola", -1));
        assertEquals("Argumento item negativo.", exception.getMessage());
    }

Y en la clase StringUtil asi:

    public static String repetir(String str,int item){
        if(item < 0){
            throw new IllegalArgumentException("Argumento item negativo.");
        }
        String resultado = "";
        for (int i = 0; i < item; i++) {
            resultado += str;
        }
        return resultado;
    }
}

Fijense que yo puse en assertEquals (test) y en el throw new illegalArgumentException (StringUtil) el mismo mensaje "Argumento item negativo."

Robinson Ganchala

student•

En lugar de poner if por todos lados deberías usar assert para controlar casos de excepción.

Rubén Hernan Barrera Chavez

student•

esque la excepcion la pusieron en el codigo y el assert dijo que era de junit se supone que las pruebas unitarias no quedan en el codigo final asi como su libreria no irian hablando en terminos de produccion

Brayan Pérez Ramos

student•

Es correcto escribir los nombres de los test con guiones bajos en lugar de ocupar camel case?

Roberto Shirásago Domínguez

student•

Parece que no, ya estuve buscando y solo aqui no la han hecho así

Wilson Alejandro Gonzalez Gaitan

student•

Aca una pagina que tiene un poco de los estandares que se manejan

Renzo Parente

student•

Hola, creo que falto el link. Saludos

SANTIAGO CANO GONZALEZ

student•

Los test para comportamientos inesperados, corrección de clases.

Bernardo Aguayo Ortega

student•

Graacias

Mati Caro

student•

¿Que es lo que mas les gusta de las pruebas unitarias?

Tara Campos Padilla

student•

Para quienes se esten actualizando: "The expected attribute is not available in JUnit 5 (JUnit Jupiter)." así que la manera correcta de pasar este test:

Organización de Tests en Funciones Separadas

Bienvenida e Introducción

Testing en Java: JUnit, Mockito y TDD

Introducción a tests en software

Beneficios y tipos de tests automáticos y manuales en software

Preparación del IDE, proyecto y librerías

Uso de IntelliJ IDEA para Escribir y Probar Código Java

Creación de Tests Unitarios y Excepciones en Java

Escribir Tests en Java con JUnit: Instalación y Uso Básico

Organización de Tests en Funciones Separadas

Testing en Java con JUnit para Verificar Contraseñas

Simulación de Clases en Java con Moquito

Simulación de Pasarelas de Pago con Mockito

Organización y Mejora de Tests en jUnit

Función `isEmpty` y pruebas con JUnit en Java

TDD

Desarrollo Guiado por Pruebas (TDD): Conceptos y Ciclo Red-Green-Refactor

TDD para calcular años bisiestos en Java

Cálculo de Descuentos con Pruebas Unitarias en Java

Programación con TDD: Ejercicios FizzBuzz y Números Romanos

Tests en una aplicación

Organización de Aplicaciones en Capas: Interfaz, Negocio y Datos

Tests de Aplicación de Películas: Filtrado por Género y Duración

Pruebas de Búsqueda de Películas por Duración en Java

Implementación de MovieRepository con JDBC en Java

Tests de JDBC: Búsqueda e Inserción de Películas por ID

Búsqueda de Películas por Nombre y Director en App

Requerimientos y tests

Escritura de Tests a partir de Requerimientos Específicos

Búsqueda de Películas por Atributos en Java

Conclusiones

Recomendaciones para Escribir Tests Efectivos en Programación