Поиск закономерностей отказа в модульном тесте

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

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

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

Что касается того, как что-то сломать, для большинства классов CRUD есть тесты на отказ, например:

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

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

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

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

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

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

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

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

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

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


person Pekka    schedule 26.03.2010    source источник


Ответы (1)


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

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

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

person Péter Török    schedule 26.03.2010
comment
Спасибо, Петер. Я все еще разбираюсь в теме и не уверен, правильно ли я все делаю, поэтому я благодарен за возможность получить здесь качественный отзыв. Просто инстинкт моего ленивца звенел в колокольчик, когда я писал, по сути, тот же тест во второй раз :) Но я понимаю вашу точку зрения о TDD и том, как автоматизировать это не главное. Я замечаю, что медленно погружаюсь в это, сначала пишу тесты, а затем модуль, что является действительно отличным способом работы. - person Pekka; 27.03.2010
comment
Практика @Pekka делает мастера, и это единственный способ добиться этого :-) Кстати, Pekka - финское имя, вы финны по происхождению? - person Péter Török; 27.03.2010
comment
@Peter, определенно есть. Re origin: Половина. Я родился в Финляндии, но вырос в Германии, так что я в значительной степени немец. Хотя я все еще немного говорю по-фински. - person Pekka; 27.03.2010