JUnit en Java

Comprueba que un método pequeño devuelve el valor que querías. En SumCheck.java mantén un Sum package-private con add, mantén la clase pública SumCheck, marca un método con @Test y llama assertEquals(5, Sum.add(2, 3));. Cuando 2 + 3 es 5, el check pasa. Un segundo demo comprueba Sum.add(4, 5) frente a 9. Deja el JAR opcional para la página siguiente. Esta lección es un check JUnit con assertEquals, no una impresión de accessor en Records ni una tubería de Streams.

Un check que quiere 5

Abre SumCheck.java. Mantén el nombre de clase pública SumCheck. Borra demos sobrantes de Card en Records, tuberías sobrantes de Pipe en Streams, recorridos sobrantes de Cue en lambda y prompts sobrantes de Scanner en Box si entierran la historia de JUnit. El archivo de enseñanza es una clase de prueba, no un main que imprima oak.
Añade los imports arriba:
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
Mantén un ayudante pequeño en el mismo archivo:
class Sum {
static int add(int left, int right) {
return left + right;
}
}
Dentro de SumCheck escribe un método de prueba:
@Test
void addsTwoAndThree() {
assertEquals(5, Sum.add(2, 3));
}
@Test marca el método como check que el runner debe ejecutar. assertEquals toma primero el valor esperado y luego el real. Aquí lo esperado es 5 y lo real es Sum.add(2, 3). Coinciden, así que el check pasa.

Compila y ejecuta este archivo con un runner JUnit 5 en tu classpath — un botón de prueba del IDE, o un launcher de consola que selecciona la clase SumCheck. El hábito del curso sigue siendo «compilar el fuente del test, luego ejecutar los checks». En esta página no lanzas java SumCheck como un programa main ordinario. No imprimes t.name(). Pides al runner que ejecute métodos @Test.
Recorre el check una vez. Sum.add(2, 3) devuelve 5. assertEquals(5, ...) compara ese 5 con el esperado 5. Coinciden. El check pasa. Una línea de informe puede mostrar un resultado en verde o un resumen corto de éxito según el runner. El hecho didáctico importante es que esperado y real coincidieron.
Di la regla de principiante mientras miras el método: @Test marca el check; assertEquals(expected, actual) compara; nombra el método para que un humano lo lea. No inventes demos de empaquetado JAR en esta página. JAR espera la lección opcional siguiente. No trates un check fallido frente a 9 como este primer demo — este primer demo quiere 5.
Si aún ves oak de un archivo sobrante de Card en Records, cambia a SumCheck y mantén assertEquals(5, Sum.add(2, 3));. Si el runner no encuentra tests, confirma que el método tiene @Test y no es privado de forma que tu runner lo rechace.

Un segundo check que quiere 9

Mantén la misma clase pública SumCheck y el mismo ayudante Sum. Cambia el cuerpo del test para comprobar otra suma:
@Test
void addsFourAndFive() {
assertEquals(9, Sum.add(4, 5));
}
4 + 5 es 9. Lo esperado es 9. Lo real es Sum.add(4, 5). Coinciden, así que este check también pasa. Mantén un check claro por forma didáctica en esta página para que el número esperado siga fácil de nombrar.

Recorre el check una vez. Sum.add(4, 5) devuelve 9. assertEquals(9, ...) compara esperado y real. Coinciden. El check pasa. Mantén los dos demos como dos formas didácticas. Primero demuestra un check que quiere 5. Luego uno que quiere 9. Ambas formas comparten los imports JUnit, el ayudante Sum y @Test.
Si el primer demo comparara Sum.add(2, 3) con 9, el check fallaría porque 5 no es 9. Ese programa fallido no es el primer archivo didáctico. El primer archivo didáctico quiere 5.

JUnit no es Records ni JAR

Records guardaban componentes compactos que imprimías con accessors. JUnit comprueba un resultado frente a un valor que esperabas. JAR empaquetará archivos de clase para enviar en una página opcional posterior. No mezcles esos tres trabajos en un archivo de principiante hoy.
5 aquí es el valor esperado en assertEquals. No es t.n() de un record Tag ni un resultado de map en stream. Cuando un archivo sobrante de Card aún imprime oak, déjalo como historia y mantén la línea de assertion de SumCheck.
Sin @Test, muchos runners no ejecutarán el método como check. Sin assertEquals, no tienes comparación en esta forma didáctica. Mantén ambos. Mantén comandos JAR fuera de esta página hasta esa lección.

Hábitos de runner y classpath

Los tipos JUnit viven en los paquetes org.junit.jupiter.api. Tu editor o herramienta de build debe poner esos jars en el classpath de compilación y ejecución. Los principiantes a menudo pegan la clase de prueba bien y aún ven «package does not exist» cuando faltan los jars — arregla el classpath, no la ortografía de @Test.
Mantén Sum package-private en el mismo archivo para que solo una clase pública sea SumCheck. Mantén valores esperados como literales claros en assertEquals. Mantén nombres de método legibles. Mantén System.out.println ordinario fuera de los checks didácticos salvo que depures por tu cuenta más tarde.
Si la compilación falla en org.junit, la línea import está bien y falta la biblioteca en el classpath. Si el runner dice cero tests encontrados, busca un @Test ausente o un nombre de clase que no seleccionaste.

Comprobaciones de carpeta antes de JAR

Lista la carpeta tras compilar con éxito con los jars JUnit disponibles. Deberías ver SumCheck.class y normalmente Sum.class junto al fuente. Edita el fuente, guarda, compila otra vez, luego ejecuta los checks con el mismo hábito de runner. Una clase obsoleta puede ocultar un valor esperado cambiado si saltas compilar tras una edición.
Si javac se queja de clases públicas duplicadas, mantén solo SumCheck pública. Si un check falla después de escribir assertEquals(9, Sum.add(2, 3)), ese desajuste es real — restaura el par coincidente para el demo que quieres mantener.
No pegues record Tag de Card en SumCheck. No sustituyas assertEquals por stream().map de Pipe. El trabajo opcional de JUnit es un check marcado que compara esperado y real.

Antes del JAR opcional

Puedes mantener la clase pública SumCheck, el ayudante Sum.add, importar @Test y assertEquals de JUnit, comprobar Sum.add(2, 3) frente a 5, luego Sum.add(4, 5) frente a 9. Compila con JUnit en el classpath y ejecuta los checks con un runner JUnit 5. La siguiente página opcional es JAR.
Mantén los demos de SumCheck para un par de assertions claro. Mantén archivos Card en Records fuera de esta página cuando practiques JUnit. Mantén archivos Pipe en Streams fuera de esta página cuando practiques JUnit. Mantén trabajo JAR fuera de esta página hasta esa lección. Esos hábitos son el punto de control antes de seguir. Cuando el primer check quiere 5 y pasa, o el segundo quiere 9 y pasa, JUnit hizo su trabajo en esta lección y estás listo para JAR si continúas el camino opcional.
Un último repaso de la carpeta: una SumCheck pública, Sum package-private, @Test presente, assertEquals(expected, actual) alineado, imports JUnit presentes, sin espera de Scanner, sin tubería stream requerida. Compila y ejecuta los checks una vez más en el demo que tienes abierto. Si esperado y real aún coinciden, la forma JUnit es sólida y el curso puede pasar a JAR opcional en la página siguiente. Prefiere un hábito de assertion claro por lectura para que cada paso enseñe el mismo mapa.