JUnit

Estructura básica: @BeforeEach -> crear SUT. @Test -> Arrange (datos entrada + esperado), Act (ejecutar método), Assert (comprobar resultado). Nombre recomendado: C1_metodo_should_result_when_condicion().

Assertions principales

• assertEquals(), assertTrue(), assertFalse(), assertNull(), assertNotNull(), assertSame(), assertNotSame(), assertArrayEquals(), assertAll(), assertThrows(), assertDoesNotThrow().

Uso avanzado:

• assertDoesNotThrow(): Comprobar que NO lanza excepción. Puede devolver resultado: Tipo result = assertDoesNotThrow(() -> sut.metodo(...));
• assertThrows(): Comprobar que SÍ lanza excepción. Excepcion ex = assertThrows(Excepcion.class, () -> sut.metodo(...)); Luego comprobar mensaje con assertEquals("mensaje", ex.getMessage()).
• assertAll(): Agrupa varias comprobaciones sin detenerse en la primera. Usar cuando se comparan muchos atributos: assertAll(() -> assertEquals(...), () -> assertEquals(...), ...);
• assertArrayEquals(): Comparar arrays completos.

Configuración: @BeforeEach evita repetir creación del SUT en cada test.

Tests parametrizados

• Un parámetro: @ParameterizedTest + @ValueSource(ints={...})
• Varios parámetros: @ParameterizedTest + @MethodSource("casos"). MethodSource devuelve Stream<Arguments>. Cada Arguments.of(...) representa un caso de prueba.

DBUnit

Objetivo: Probar métodos que acceden a BD utilizando una BD real controlada mediante XML.

Flujo general

1. Crear JdbcDatabaseTester.
2. Crear SUT.
3. Leer XML inicial.
4. setDataSet().
5. onSetup().
6. Ejecutar método.
7. Comprobar resultado.

Crear DatabaseTester: databaseTester = new JdbcDatabaseTester(driver, cadenaConexion, login, password);

Preparar BD:
IDataSet dataSet = leerDatos("/inicio.xml");
databaseTester.setDataSet(dataSet);
databaseTester.onSetup();

Nota: FlatXmlDataSetBuilder() permite leer XML manualmente si no existe método leerDatos().

Caja Negra

Objetivo: Diseñar casos de prueba únicamente a partir de la especificación o requisitos, sin conocer el código fuente.

Particiones equivalentes

Consiste en dividir el dominio de entrada en particiones (clases) cuyos valores se espera que produzcan el mismo comportamiento. De cada partición basta probar un representante.

• Particiones válidas: Entradas que cumplen la especificación.
• Particiones inválidas: Entradas que incumplen la especificación y deben provocar error o rechazo.

Heurísticas para construir particiones

• Rangos: Si una variable está definida mediante un intervalo, normalmente aparecen tres particiones (ej. Edad 18-65: <18, 18-65, >65).
• Valores concretos: Cuando solo se permiten determinados valores (ej. Sexo H/M).
• Conjuntos finitos: Cuando la entrada pertenece a un conjunto de opciones (ej. Métodos de pago).
• Dependencia entre variables: Si una variable condiciona a otra, las particiones deben construirse conjuntamente.
• Particiones no homogéneas: Si una partición produce comportamientos distintos, debe subdividirse (ej. Importe > 0: hasta 100€ vs más de 100€).

Cobertura (JaCoCo)

Objetivo: Medir cuánto código ejecutan los tests.

• Métricas: Instructions, Lines, Branches, Methods, Classes, Complexity.
• Criterios: Líneas, Decisiones (Branch), Condiciones, Multicondición y Caminos.

JMeter

Objetivo: Pruebas de carga y rendimiento.

• Componentes clave: Thread Group, HTTP Request, Response Assertion, View Results Tree, Aggregate Report, Timers (Constant, Synchronizing) y Controllers (Loop, Once Only, Interleave).

Caja Blanca

CFG (Control Flow Graph)

• Nodos: Bloques de instrucciones que siempre se ejecutan juntos.
• Aristas: Posibles transiciones entre nodos.

Complejidad ciclomática (CC)

Mide el número de caminos independientes del programa.
CC = Decisiones + 1 o CC = Aristas − Nodos + 2.

Diseño de casos

1. Construir el CFG.
2. Numerar nodos y aristas.
3. Calcular la complejidad ciclomática.
4. Obtener los caminos independientes.
5. Elegir datos de entrada que recorran exactamente cada camino.