Поиск шаблонов сбоев в модульном тесте

Question

Я новичок в модульном тестировании, и я только начинаю строить наборы тестов. У меня есть довольно большой проект, для которого я хочу построить тесты с самого начала.

Я пытаюсь выяснить общие стратегии и шаблоны для построения тестовых наборов. Когда вы смотрите на класс, многие тесты приходят к вам, очевидно, из-за характера класса. Скажем, для класса «учетная запись пользователя» с базовыми операциями CRUD, связанного с таблицей базы данных, мы захотим проверить - ну, CRUD.

• создание объекта и проверка его существования
• запросить его свойства
• изменить некоторые свойства
• изменить некоторые свойства на неправильные значения
• и удалите его снова.

Что касается того, как что-то сломать, то существуют тесты «fail», общие для большинства классов CRUD, такие как:

• Неверные типы входных данных
• Число в качестве идентификатора ключа, превышающее диапазон выбранного типа данных
• Ввод в неправильной кодировке
• слишком длинный ввод

И так далее, и так далее.

Для модульного теста, связанного с файловыми операциями, список «ломающихся вещей» может быть

• Недопустимые символы в имени файла
• Имя файла слишком длинное
• Имя файла использует неверный протокол или путь

Я почти уверен, что аналогичные паттерны, применимые за пределами модульного теста, над которым сейчас ведется работа, можно найти для большинства тестируемых юнитов.

Теперь мой вопрос:

• Правильно ли я вижу такие "ломающиеся образцы"? Или я что-то не так понимаю в модульном тестировании, и если я все сделал правильно, это не будет проблемой вообще? Является ли модульное тестирование процессом поиска как можно большего количества способов сломать устройство, как это возможно?

• Если я прав: существуют ли определения, списки, шпаргалки для таких шаблонов?

• Существуют ли какие-либо положения (в основном в PHPUnit, поскольку это среда, в которой я работаю) для автоматизации таких шаблонов?

• Есть ли какая-либо помощь - в виде контрольных списков или программного обеспечения - для помощи в написании полных тестов?

Answer 1

Вы в основном правы. Поиск путей, которые могли бы сломать ваш код, является ключевой частью и навыком модульного тестирования. Тем не менее, модульное тестирование, применяемое в TDD, работает немного иначе. В TDD вы сначала пишете тест для новой функциональности, а затем создаете код, чтобы выполнить этот тест. Таким образом, акцент здесь другой, хотя конечный результат похож.

В TDD постоянно "меняются шляпы" - немного тестирования, немного кодирования. Таким образом, в этом методе тестирование не является автоматизируемой частью, но можно почти сказать, что это ключ к творческому процессу. При написании тестов вы также разрабатываете интерфейс вашего устройства и думаете с точки зрения его (будущих) клиентов - что они могут ожидать и что они должны предоставить? Затем вы переключаете шляпы и заходите внутрь устройства, чтобы оправдать эти ожидания.

Так что я не чувствую, что это можно заменить простой проверкой пунктов в списке. Конечно, если у вас закончились идеи по тестированию реального устройства, проверка такого списка никогда не повредит. Однако такие листы по своей природе могут содержать только обобщения, которые могут или не могут применяться к конкретному проекту и конкретному классу для тестирования. Но у вас, очевидно, есть опыт и мышление, чтобы найти хорошие тестовые примеры для ваших конкретных подразделений: -)