Нахождение шаблонов отказа в Модульном тесте
Я плохо знаком с Поблочным тестированием, и я только вхожу в стандартную программу создания наборов тестов. Я имею то, что будет довольно крупным проектом, для которого я хочу создать тесты из запуска.
Я пытаюсь выяснить общие стратегии и шаблоны для создания наборов тестов. При рассмотрении класса много тестов прибывают к Вам очевидно из-за природы класса. Скажите для класса "учетной записи пользователя" с основными операциями CRUD, будучи связанным с таблицей базы данных, мы захотим протестировать - хорошо, CRUD.
- создание объекта и наблюдение, существует ли это
- запросите его свойства
- измените некоторые свойства
- измените некоторые свойства на неправильные значения
- и удалите его снова.
Что касается того, как повредить вещи, существуют тесты "сбоя", характерные для большинства классов CRUD как:
- Недопустимые типы входных данных
- Число как идентификационный ключ, который превышает диапазон выбранного типа данных
- Вход в неправильной кодировке символов
- Вход, который является слишком длинным
И так далее и так далее.
Для модульного теста, касавшегося операций файла, список "повреждающихся вещей" мог быть
- Недопустимые символы в имени файла
- Имя файла слишком долго
- Имя файла использует неправильный протокол или путь
Я - вполне уверенные подобные шаблоны - применимый вне модульного теста, каждый в настоящее время продолжает работать - может быть найден для большинства единиц, которые тестируются.
Теперь мой вопрос:
Я корректен в наблюдении таких "шаблонов повреждения"? Или я получаю что-то абсолютно неправильное относительно Поблочного тестирования, и если бы я сделал его правильно, то это не было бы проблемой вообще? Действительно ли Поблочное тестирование как процесс нахождения как можно большего количества способов повредить единицу правильный способ пойти?
Если я корректен: Есть ли существующие определения, списки, шпаргалки для таких шаблонов?
Есть ли какие-либо условия (главным образом в PHPUnit, поскольку это - платформа, я работаю в) автоматизировать такие шаблоны?
Есть ли помощь - в форме контрольных списков или программного обеспечения - для помощи в записи полных тестов?
1 ответ
Вы в основном правы. Поиск способов, которые могут привести к поломке вашего кода, является ключевым моментом и навыком в модульном тестировании. Однако модульное тестирование, применяемое в TDD, работает несколько иначе. В TDD вы сначала пишете тест для новой функциональности, а затем создаете код, чтобы этот тест прошел. Таким образом, здесь другой акцент, хотя конечный результат похож.
В TDD постоянно «меняют шляпу» - немного тестирования, немного кодирования. Таким образом, в этом методе тестирование не является автоматизированной частью, но можно почти сказать, что это ключ к творческому процессу. При написании тестов вы также разрабатываете интерфейс своего модуля и думаете с точки зрения его (будущих) клиентов - чего они могут ожидать и что они должны предоставить? Затем вы меняете шляпы и заходите внутрь, чтобы оправдать эти ожидания.
Поэтому я не думаю, что это можно заменить простой проверкой элементов в списке. Конечно, если у вас закончатся идеи для тестирования реального устройства, никогда не помешает проверить такой список. Однако такие листы по своей природе могут содержать только обобщения, которые могут или не могут применяться к конкретному проекту и конкретному классу для тестирования. Но у вас, по-видимому, есть опыт и образ мышления, чтобы в любом случае найти хорошие тестовые примеры для ваших конкретных модулей: -)