Junit Test Classes And Methods
Junit: Test Classes and Methods
Los métodos de prueba y los métodos de ciclo de vida pueden declararse localmente dentro de la clase de prueba actual, heredarse de superclases o heredarse de interfaces (consulta Interfaces de Prueba y Métodos por Defecto). Además, los métodos de prueba y los métodos de ciclo de vida no deben ser abstract y no deben devolver un valor (excepto los métodos anotados con @TestFactory, que están obligados a devolver un valor).
❕️Class and method visibilidad
Las clases de prueba, los métodos de prueba y los métodos de ciclo de vida no están obligados a ser públicos, pero no deben ser privados.
Se recomienda, en general, omitir el modificador public para clases de prueba, métodos de prueba y métodos de ciclo de vida, a menos que exista una razón técnica para hacerlo. Por ejemplo, cuando una clase de prueba es extendida por otra clase de prueba en un paquete diferente. Otra razón técnica para hacer que las clases y métodos sean públicos es simplificar las pruebas en la ruta de módulos al usar el Sistema de Módulos de Java.
Field and method inheritance
Los atributos en las clases de prueba son heredados. Por ejemplo, un campo anotado con @TempDir en una superclase siempre se aplicará en una subclase.
Los métodos de prueba y los métodos del ciclo de vida también se heredan, a menos que sean sobrescritos según las reglas de visibilidad del lenguaje Java. Por ejemplo, un método anotado con @Test en una superclase siempre se aplicará en una subclase, a menos que la subclase sobrescriba explícitamente dicho método. De manera similar, si un método @Test con modificador de acceso package-private(modificar por defecto) es declarado en una superclase que se encuentra en un paquete diferente al de la subclase, ese método @Test siempre se aplicará en la subclase, ya que la subclase no puede sobrescribir un método package-private de una superclase ubicada en un paquete distinto.
See also: Field and Method Search Semantics
Ejemplo rápido:
// En el paquete com.ejemplo.base
package com.ejemplo.base;
public class PruebaBase {
@Test
void testMetodo() {
System.out.println("Desde PruebaBase");
}
}
// En el paquete com.ejemplo.derivado
package com.ejemplo.derivado;
public class PruebaDerivada extends PruebaBase {
// No puedes sobrescribir testMetodo aquí porque es package-private
}
Aquí, testMetodo() se ejecutará en PruebaDerivada, pero tú no puedes sobrescribirlo ahí porque no es visible desde otro paquete.
La siguiente clase de prueba demuestra el uso de métodos @Test y todos los métodos de ciclo de vida compatibles. For further information on runtime semantics, see Test Execution Order and Wrapping Behavior of Callbacks.
A standard test class
import static org.junit.jupiter.api.Assertions.fail;
import static org.junit.jupiter.api.Assumptions.assumeTrue;
import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Test;
class StandardTests {
@BeforeAll
static void initAll() {
}
@BeforeEach
void init() {
}
@Test
void succeedingTest() {
}
@Test
void failingTest() {
fail("a failing test");
}
@Test
@Disabled("for demonstration purposes")
void skippedTest() {
// not executed
}
@Test
void abortedTest() {
assumeTrue("abc".contains("Z"));
fail("test should have been aborted");
}
@AfterEach
void tearDown() {
}
@AfterAll
static void tearDownAll() {
}
}
También es posible usar clases record de Java como clases de prueba, como se ilustra en el siguiente ejemplo.
import static org.junit.jupiter.api.Assertions.assertEquals;
import example.util.Calculator;
import org.junit.jupiter.api.Test;
record MyFirstJUnitJupiterRecordTests() {
@Test
void addition() {
assertEquals(2, new Calculator().add(1, 1));
}
}