JUnit в Java

Проверьте, что небольшой метод возвращает значение, которое вы ожидали. В SumCheck.java оставьте package-private Sum с методом add, сохраните public-класс SumCheck, пометьте метод аннотацией @Test и вызовите assertEquals(5, Sum.add(2, 3));. Когда 2 + 3 равно 5, проверка проходит. Вторая демонстрация сравнивает Sum.add(4, 5) с 9. Опциональный JAR оставьте на следующую страницу. Этот урок — проверка JUnit с assertEquals, а не печать accessor в Records и не конвейер Streams.

Одна проверка, которая ждёт 5

Откройте SumCheck.java. Оставьте public-имя класса SumCheck. Удалите оставшиеся демо Card с records, оставшиеся конвейеры Pipe со streams, оставшиеся проходы Cue с lambda и оставшиеся запросы Scanner в Box, если они заслоняют историю JUnit. Учебный файл — тестовый класс, а не main, который печатает oak.
Добавьте import в начало файла:
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
Оставьте крошечный помощник в том же файле:
class Sum {
static int add(int left, int right) {
return left + right;
}
}
Внутри SumCheck напишите один тестовый метод:
@Test
void addsTwoAndThree() {
assertEquals(5, Sum.add(2, 3));
}
@Test помечает метод как проверку, которую runner должен выполнить. assertEquals принимает сначала ожидаемое значение, потом фактическое. Здесь ожидаемое — 5, а фактическое — Sum.add(2, 3). Они совпадают, поэтому проверка проходит.

Скомпилируйте и запустите этот файл с runner JUnit 5 в classpath — кнопка теста в IDE или консольный launcher jar, который выбирает класс SumCheck. Привычка курса по-прежнему «скомпилировать исходник теста, затем запустить проверки». На этой странице вы не запускаете java SumCheck как обычную программу с main. Вы не печатаете t.name(). Вы просите runner выполнить методы с @Test.
Пройдите проверку один раз по шагам. Sum.add(2, 3) возвращает 5. assertEquals(5, ...) сравнивает это 5 с ожидаемым 5. Они совпадают. Проверка проходит. В отчёте может быть зелёный результат или короткое сообщение об успехе — зависит от runner. Важный учебный факт: ожидаемое и фактическое совпали.
Произнесите правило для новичка, глядя на метод: @Test помечает проверку; assertEquals(expected, actual) сравнивает; назовите метод так, чтобы человек мог его прочитать. Не выдумывайте демо упаковки JAR на этой странице. JAR ждёт следующего опционального урока. Не считайте провалившуюся проверку против 9 первой демонстрацией — первая демо ждёт 5.
Если вы всё ещё видите oak из оставшегося файла Card с records, переключитесь на SumCheck и оставьте assertEquals(5, Sum.add(2, 3));. Если runner не находит тестов, убедитесь, что у метода есть @Test и он не private так, что runner его отвергает.

Вторая проверка, которая ждёт 9

Оставьте тот же public-класс SumCheck и того же помощника Sum. Измените тело теста, чтобы проверить другую сумму:
@Test
void addsFourAndFive() {
assertEquals(9, Sum.add(4, 5));
}
4 + 5 равно 9. Ожидаемое — 9. Фактическое — Sum.add(4, 5). Они совпадают, поэтому эта проверка тоже проходит. На этой странице держите одну ясную проверку на учебную форму, чтобы ожидаемое число было легко назвать.

Пройдите проверку один раз по шагам. Sum.add(4, 5) возвращает 9. assertEquals(9, ...) сравнивает ожидаемое и фактическое. Они совпадают. Проверка проходит. Две демонстрации — две учебные формы. Сначала докажите проверку, которая ждёт 5. Потом — проверку, которая ждёт 9. Обе формы разделяют import JUnit, помощника Sum и @Test.
Если первая демо сравнивала бы Sum.add(2, 3) с 9, проверка бы упала, потому что 5 не равно 9. Такая падающая программа — не первый учебный файл. Первый учебный файл ждёт 5.

JUnit — это не Records и не JAR

Records хранили компактные компоненты, которые вы печатали через accessors. JUnit сверяет результат со значением, которое вы ожидали. JAR позже упакует class-файлы для передачи на опциональной странице. Не смешивайте эти три роли в одном начальном файле сегодня.
5 здесь — ожидаемое значение в assertEquals. Это не t.n() из record Tag и не результат map в stream. Когда оставшийся файл Card всё ещё печатает oak, оставьте это как историю и сохраните строку assertion в SumCheck.
Без @Test многие runner не выполнят метод как проверку. Без assertEquals в этой учебной форме нет сравнения. Сохраните оба. Держите команды JAR вне этой страницы до того урока.

Привычки runner и classpath

Типы JUnit живут в пакетах org.junit.jupiter.api. Редактор или сборщик должен положить соответствующие jar в classpath компиляции и запуска. Новички часто вставляют тестовый класс правильно и всё равно видят «package does not exist», когда jar нет — чините classpath, а не написание @Test.
Держите Sum package-private в том же файле, чтобы единственным public-классом оставался SumCheck. Ожидаемые значения оставляйте явными литералами в assertEquals. Имена методов — читаемыми. Обычный System.out.println уберите из учебных проверок, если только вы сами не отлаживаете позже.
Если компиляция падает на org.junit, строка import в порядке, а библиотеки нет в classpath. Если runner говорит, что найдено ноль тестов, ищите пропавший @Test или класс, который вы не выбрали.

Проверка папки перед JAR

После успешной компиляции с доступными jar JUnit просмотрите папку. Должны быть SumCheck.class и обычно Sum.class рядом с исходником. Отредактируйте исходник, сохраните, снова скомпилируйте, затем запустите проверки той же привычкой runner. Устаревший class может скрыть изменённое ожидаемое значение, если вы пропустите компиляцию после правки.
Если javac жалуется на дублирующиеся public-классы, public оставьте только у SumCheck. Если проверка падает после assertEquals(9, Sum.add(2, 3)), несоответствие настоящее — верните согласованную пару для демо, которое хотите оставить.
Не вставляйте record Tag из Card в SumCheck. Не подставляйте stream().map из Pipe вместо assertEquals. Опциональная задача JUnit — помеченная проверка, которая сравнивает ожидаемое и фактическое.

Перед опциональным JAR

Вы можете оставить public-класс SumCheck, помощника Sum.add, импортировать JUnit @Test и assertEquals, проверить Sum.add(2, 3) против 5, затем Sum.add(4, 5) против 9. Скомпилируйте с JUnit в classpath и запустите проверки через runner JUnit 5. Следующая опциональная страница — JAR.
Держите демо SumCheck для ясной пары assertion. Уберите файлы Card с records с этой страницы, когда тренируете JUnit. Уберите файлы Pipe со streams с этой страницы, когда тренируете JUnit. Работу с JAR отложите до того урока. Эти привычки — контрольная точка перед продолжением. Когда первая проверка ждёт 5 и проходит, или вторая ждёт 9 и проходит, JUnit выполнил свою работу в этом уроке, и вы готовы к JAR, если идёте по опциональному пути.
Последний проход по папке: один public SumCheck, package-private Sum, @Test на месте, assertEquals(expected, actual) выровнен, import JUnit на месте, без ожидания Scanner, без обязательного конвейера stream. Скомпилируйте и ещё раз запустите проверки на демо, которое держите открытым. Если ожидаемое и фактическое всё ещё совпадают, форма JUnit крепкая, и курс может перейти к опциональному JAR на следующей странице. На каждое чтение оставляйте одну ясную привычку assertion, чтобы каждый проход учил ту же карту.