JUnit em Java

Verifique se um método pequeno devolve o valor que você queria. Em SumCheck.java, mantenha um Sum package-private com add, mantenha a classe pública SumCheck, marque um método com @Test e chame assertEquals(5, Sum.add(2, 3));. Quando 2 + 3 é 5, a verificação passa. Uma segunda demo verifica Sum.add(4, 5) contra 9. Deixe o JAR opcional para a página seguinte. Esta lição é uma verificação JUnit com assertEquals, não uma impressão de accessor de Records e não um pipeline de Streams.

Uma verificação que quer 5

Abra SumCheck.java. Mantenha o nome da classe pública SumCheck. Apague demos de Records Card que sobraram, pipelines de Streams Pipe que sobraram, caminhadas lambda Cue que sobraram e prompts Scanner de Box se enterrarem a história do JUnit. O arquivo de ensino é uma classe de teste, não um main que imprime oak.
Adicione os imports no topo:
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
Mantenha um helper pequeno no mesmo arquivo:
class Sum {
static int add(int left, int right) {
return left + right;
}
}
Dentro de SumCheck, escreva um método de teste:
@Test
void addsTwoAndThree() {
assertEquals(5, Sum.add(2, 3));
}
@Test marca o método como uma verificação que o runner deve executar. assertEquals recebe primeiro o valor esperado e depois o real. Aqui o esperado é 5 e o real é Sum.add(2, 3). Coincidem, então a verificação passa.

Compile e execute este arquivo com um runner JUnit 5 no classpath — botão de teste da IDE, ou launcher de console que seleciona a classe SumCheck. O hábito do curso ainda é «compilar o fonte do teste, depois rodar as verificações». Você não inicia java SumCheck como programa main comum nesta página. Você não imprime t.name(). Você pede ao runner que execute os métodos @Test.
Percorra a verificação uma vez. Sum.add(2, 3) devolve 5. assertEquals(5, ...) compara esse 5 com o esperado 5. Coincidem. A verificação passa. Uma linha de relatório pode mostrar resultado verde ou um resumo curto de sucesso, conforme o runner. O fato de ensino importante é que esperado e real concordaram.
Diga a regra do iniciante enquanto olha o método: @Test marca a verificação; assertEquals(expected, actual) compara; nomeie o método para um humano ler. Não invente demos de empacotamento JAR nesta página. JAR espera a lição opcional seguinte. Não trate verificação falhando contra 9 como esta primeira demo — esta primeira demo quer 5.
Se ainda vir oak de um arquivo Records Card que sobrou, mude para SumCheck e mantenha assertEquals(5, Sum.add(2, 3));. Se o runner não encontrar testes, confirme que o método tem @Test e não é private de um jeito que seu runner rejeite.

Uma segunda verificação que quer 9

Mantenha a mesma classe pública SumCheck e o mesmo helper Sum. Mude o corpo do teste para verificar outra soma:
@Test
void addsFourAndFive() {
assertEquals(9, Sum.add(4, 5));
}
4 + 5 é 9. O esperado é 9. O real é Sum.add(4, 5). Coincidem, então esta verificação também passa. Mantenha uma verificação clara por forma de ensino nesta página para o número esperado continuar fácil de nomear.

Percorra a verificação uma vez. Sum.add(4, 5) devolve 9. assertEquals(9, ...) compara esperado e real. Coincidem. A verificação passa. Mantenha as duas demos como duas formas de ensino. Primeiro prove uma verificação que quer 5. Depois prove uma que quer 9. Ambas as formas compartilham imports JUnit, helper Sum e @Test.
Se a primeira demo comparasse Sum.add(2, 3) com 9, a verificação falharia porque 5 não é 9. Esse programa falhando não é o primeiro arquivo de ensino. O primeiro arquivo de ensino quer 5.

JUnit não é Records nem JAR

Records guardavam componentes compactos que você imprimia com acessores. JUnit verifica um resultado contra um valor que você esperava. JAR empacotará arquivos de classe para envio numa página opcional depois. Não misture esses três papéis num único arquivo iniciante hoje.
Aqui 5 é o valor esperado em assertEquals. Não é t.n() de um record Tag nem resultado de map em stream. Quando um arquivo Card que sobrou ainda imprime oak, deixe isso como histórico e mantenha a linha de asserção do SumCheck.
Sem @Test, muitos runners não executarão o método como verificação. Sem assertEquals, não há comparação nesta forma de ensino. Mantenha ambos. Mantenha comandos JAR fora desta página até aquela lição.

Hábitos de runner e classpath

Os tipos JUnit vivem nos pacotes org.junit.jupiter.api. Seu editor ou ferramenta de build deve colocar esses jars no classpath de compilação e execução. Iniciantes costumam colar a classe de teste corretamente e ainda ver «package does not exist» quando faltam jars — corrija o classpath, não a grafia de @Test.
Mantenha Sum package-private no mesmo arquivo para só uma classe pública ficar SumCheck. Mantenha valores esperados como literais claros em assertEquals. Mantenha nomes de método legíveis. Mantenha System.out.println comum fora das verificações de ensino, a menos que depurar por conta própria.
Se a compilação falhar em org.junit, a linha import está certa e a biblioteca falta no classpath. Se o runner disser zero testes encontrados, procure @Test ausente ou nome de classe que você não selecionou.

Checagens de pasta antes de JAR

Liste a pasta após compilação bem-sucedida com jars JUnit disponíveis. Você deve ver SumCheck.class e em geral Sum.class ao lado do fonte. Edite o fonte, salve, compile de novo e rode as verificações com o mesmo hábito de runner. Classe antiga pode esconder valor esperado alterado se pular compilação após editar.
Se javac reclamar de classes públicas duplicadas, mantenha só SumCheck pública. Se uma verificação falhar depois de digitar assertEquals(9, Sum.add(2, 3)), essa incompatibilidade é real — restaure o par correspondente para a demo que quer manter.
Não cole record Tag de Card no SumCheck. Não substitua assertEquals por stream().map de Pipe. O trabalho JUnit opcional é uma verificação marcada que compara esperado e real.

Antes do JAR opcional

Você pode manter a classe pública SumCheck, o helper Sum.add, importar @Test e assertEquals do JUnit, verificar Sum.add(2, 3) contra 5, depois Sum.add(4, 5) contra 9. Compile com JUnit no classpath e rode as verificações com um runner JUnit 5. A próxima página opcional é JAR.
Mantenha as demos SumCheck para um par de asserções claro. Mantenha arquivos Records Card fora desta página ao praticar JUnit. Mantenha arquivos Streams Pipe fora desta página ao praticar JUnit. Mantenha trabalho JAR fora desta página até aquela lição. Esses hábitos são o checkpoint antes de avançar. Quando a primeira verificação quer 5 e passa, ou a segunda quer 9 e passa, o JUnit fez o trabalho desta lição e você está pronto para JAR se continuar o caminho opcional.
Uma última passagem na pasta: um SumCheck público, Sum package-private, @Test presente, assertEquals(expected, actual) alinhado, imports JUnit presentes, sem espera de Scanner, sem pipeline stream obrigatório. Compile e rode as verificações mais uma vez na demo que mantém aberta. Se esperado e real ainda coincidem, a forma JUnit está sólida e o curso pode seguir para JAR opcional na página seguinte. Prefira um hábito de asserção claro por leitura para cada passagem ensinar o mesmo mapa.