Сначала задайте контракт простыми словами
Представим правило: название заметки обязательно, не может состоять только из пробелов и содержит не больше двадцати символов. При ошибке заметка не сохраняется, а пользователь получает понятное сообщение. Это уже набор проверяемых требований. Фраза сделай правильную валидацию слишком неопределённа. Нужно отдельно решить, удаляются ли пробелы по краям, как рассматривается отсутствующее поле и к какой строке применяется ограничение длины. Разные решения могут выглядеть разумно, но давать разный результат. Добавьте сведения об используемых версиях и уже существующей структуре проекта. Пример для другой версии библиотек может потребовать других импортов или настроек. Подтверждать соответствие следует документацией выбранного проекта, а не уверенным объяснением рядом с фрагментом. Для учебной постановки достаточно вымышленных данных. Секреты, ключи доступа и реальные пользовательские записи не нужны, чтобы описать проверку названия заметки.
Объявить ограничение и применить его не одно и то же
В Spring проверка входных объектов может использовать Bean Validation. Ограничения описывают допустимые значения, а механизм валидации должен быть подключён и вызван в соответствующем месте. Наличие похожей аннотации в классе ещё не доказывает прохождение нужной проверки при запросе. Поэтому полезно проследить весь путь: входные данные, создание объекта, проверка, обработка ошибки и сохранение. Если ошибку обнаружили, но затем всё равно вызвали сохранение, отдельное ограничение не выполнило задачу целиком. Не смешивайте также проверку формы данных с правилами предметной области. Длина названия относится к одному вопросу, а право изменять чужую заметку к другому. Успешная проверка длины не подтверждает наличие проверки прав. Сначала попросите объяснить этот путь по шагам, затем сопоставьте объяснение с реальным кодом. Несоответствие между рассказом и выполнением важнее красивых комментариев.
Проверьте границы и побочные действия
Для выбранного правила нужны не только удачные входные данные. Рассмотрите отсутствующее название, пустую строку, одни пробелы, допустимое короткое название и значения на границе длины. Если максимум равен двадцати, полезно отдельно проверить двадцать и двадцать один символ. Для каждого случая заранее запишите ожидаемый ответ и факт сохранения. Так проверяется не только сообщение об ошибке, но и отсутствие нежелательной записи. Это особенно важно, когда фрагмент затрагивает несколько слоёв приложения. Проверка сборки отвечает на вопрос о согласованности кода и зависимостей. Проверки поведения отвечают на другие вопросы. Один успешно выполненный сценарий не заменяет граничные и ошибочные случаи. После изменения требования пересмотрите примеры. Если теперь пробелы по краям удаляются, нужно уточнить порядок нормализации и измерения длины. Иначе тест и реализация могут по-разному понимать одно короткое предложение.
Попробуйте на практике
Составьте бумажную таблицу проверки контроллера заметок без написания и запуска приложения.
- Запишите правило для названия и отдельно решите, как обрабатываются пробелы по краям. Максимальную длину установите в двадцать символов.
- Подготовьте шесть случаев: отсутствующее значение, пустая строка, пробелы, короткое название, двадцать и двадцать один символ.
- Для каждого случая отметьте ожидаемое принятие или отклонение и допустимость сохранения. Уточните спорные места требования.
- Нарисуйте цепочку от запроса до сохранения. Отметьте точку проверки и путь ошибки, на котором запись создаваться не должна.
Как проверить результат. У каждого примера есть однозначное ожидание. Ошибочные данные не приводят к сохранению, а успешная сборка не используется как единственное доказательство правильности.
Частые вопросы
Можно ли просить нейросеть написать и код, и тесты?
Можно использовать такой черновик, но ожидания следует сверить с независимыми требованиями. Иначе тесты способны повторить то же ошибочное допущение, что и код.
Нужны ли сразу десятки сложных проверок?
Начните с существенных правил и их границ. Для маленького изменения несколько продуманных случаев полезнее большого числа проверок, которые повторяют один успешный путь.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.