По мере роста вашего проекта вы обнаружите, что модульные тесты намного лучше подходят для тестирования вашего кода.
Сам проект Django находится в процессе преобразования всех тестов документации в модульные тесты (мы закончим с выпуском 1.3). Причина, по которой мы делаем это, заключается в том, что до этого преобразования порядок выполнения в наборе тестов иногда приводил к трудно воспроизводимым ошибкам. Иногда небольшой фрагмент кода может случайно зависеть от ранее запущенного кода тестирования. Кроме того, переход на модульные тесты ускоряет общее время тестирования, поскольку мы можем более разумно подходить к тому, как и когда очищать базу данных.
Другое преимущество unittests состоит в том, что их НАМНОГО проще поддерживать. Поскольку весь тестовый пример является самодостаточным, вы либо пишете другой тестовый пример, либо изменяете небольшую целевую тестовую функцию в соответствии с требованиями.
Доктесты обычно работают путем эволюции - вы получаете экземпляр своего виджета, добавляете зеленый мех, убедитесь, что мех зеленый, добавляете 4 ноги, убедитесь, что у вас 4 ноги и зеленый мех, добавляете большой палец, убедитесь, что у вас есть большой палец , 4 ноги, зеленый мех и т. Д. Это означает, что если вы хотите добавить тест сразу после этапа с зеленым мехом, вы должны изменить ожидаемые результаты для каждого следующего следующего тестового примера.
Вы не хотите делать все это переписывание, поэтому вы добавляете новый тест в конце. Затем вы добавляете еще одну, и через некоторое время ваши тесты настолько безнадежно перемешаны, что вы не можете понять, протестирована ли конкретная функция или нет! С модульными тестами, поскольку каждый тест воплощает конкретную, конкретную и ограниченную идею, гораздо проще логически переупорядочить тесты и добавить новый тест, который не зависит от всех предыдущих. Кроме того, если вы измените способ add_green_fur() работы, вам не придется изменять десятки результатов тестового набора.
Другое преимущество состоит в том, что модульные тесты (если они хорошо написаны) точно скажут вам, где произошел сбой вашего кода. Failed: MyWidget.tests.test_green_fur() намного проще отлаживать, чем «тест виджета не прошел на строке 384», который часто находится на расстоянии от десятков до сотен строк от фактической точки отказа.
В общем, юнит-тесты - лучший способ тестирования.
Изменить:
В ответ на идею вашего коллеги я с уважением предлагаю, чтобы он не работал над большим проектом с большим количеством тестов. Доктесты в моделях так же плохи, как и в просмотрах. У них точно такие же проблемы (хотя доктесты хуже в моделях, потому что flush очень дорого и абсолютно необходимо для тщательного тестирования). Не стоит недооценивать время, затрачиваемое на выполнение тестов.
Кроме того, не смешивайте типы тестов, если у вас нет ОЧЕНЬ веской причины для этого. Если вы это сделаете, вы очень быстро обнаружите, что дублируете тесты или предполагаете, что функция тестируется в любом наборе тестов, на который вы случайно не смотрите.
Доктесты часто рекламируются как «предоставление документации» о том, как должен работать ваш код. Это хорошо, но не заменяет написания читаемого кода с хорошо читаемыми встроенными комментариями. Если вам нужна дополнительная документация, напишите ее отдельно!
Нельзя писать хорошие тесты, которые одновременно работают как хорошая документация.
person
Paul McMillan
schedule
22.11.2010
