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

Question

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

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

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

А как ломать вещи, есть «провал» тесты, общие для большинства классов CRUD как:

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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