#python #django #unit-testing #testing #code-coverage
#python #django #модульное тестирование #тестирование #покрытие кода
Вопрос:
Моим тестам серьезно не хватает, и я не очень верю в них. Каковы некоторые из лучших практик для получения максимального охвата тестированием, которые я могу использовать с помощью Django / Python? Я рассматривал Freshen и Lettuce, которые выглядят довольно многообещающе, но я не могу использовать их для всего, не так ли? Я ищу совет о том, как структурировать мой рабочий процесс / проект с помощью тестирования, чтобы я мог чувствовать себя уверенно при развертывании нового кода в производственной среде.
Ответ №1:
-
Прекратите кодирование.
-
Напишите тесты для того, что должно выполнять ваше приложение.
Во-первых, используйте встроенное тестирование Django. Пишите тесты модели в виде классов TestCase внутри вашего models.py .
Сделайте это сейчас. Прежде чем читать дальше. Прямо сейчас добавьте django.test.TestCase классы, которые создают, изменяют и извлекают объекты модели. Убедитесь, что у вас есть метод тестирования для каждого свойства, атрибута или дополнительного метода, который вы определили.
Я подожду, пока вы закончите это.
Тесты модели завершены? Хорошо.
Теперь создайте tests.py файл в каждом приложении. Все до единого. Все пусто.
В каждом tests.py создайте django.test.TestCase классы для каждой формы.
Сделайте это сейчас. Создавайте хорошие и плохие формы. Создавайте формы с каждой отдельной проблемой проверки полей.
Не создавайте все возможные перестановки неверных данных. Только один тестовый пример для каждого отдельного правила проверки.
Сделайте это сейчас. Прежде чем читать дальше. Добавить django.test.TestCase классы в tests.py для каждой формы.
Я подожду, пока вы закончите это.
Теперь вам нужно протестировать каждую функцию просмотра. Они также входят в tests.py файл. Каждая функция просмотра имеет как минимум два тестовых примера, возможно, больше, в зависимости от различных декораторов, которые вы используете.
Если функция просмотра требует входа в систему, у вас есть два случая: авторизованный и не авторизованный.
Если для функции просмотра требуется разрешение, у вас есть по крайней мере три случая: не авторизован, зарегистрирован как неправильный пользователь, зарегистрирован как правильный пользователь.
На данный момент вам просто нужно быть уверенным, что функция view что-то сделала и возвращает правильный HTML-шаблон с любым фрагментом правильных данных. Не сходите с ума. Вы просто хотите быть уверены, что все функции просмотра действительно возвращают ожидаемую страницу. Не более того.
Сделайте это сейчас. Прежде чем читать дальше. Добавить django.test.TestCase классы в tests.py для каждой функции просмотра.
Я подожду, пока вы закончите это.
Это тесты, которые вы должны написать сначала перед написанием любого кода приложения.
Это даст вам базовую линию тестирования, которая подтверждает, что ваше приложение будет выполняться с минимальным количеством запусков.
Когда вы закончите с этим, вы можете приступить к рассмотрению модульных тестов, которые отражают реальную цель и ценность вашего приложения.
Комментарии:
1. Я использую эту стратегию, и единственная ошибка, которую я вижу в этом подходе, заключается в том, что (по крайней мере, я был) может возникнуть желание вложить слишком много бизнес-логики в модели и / или формы (вместо того, чтобы ждать, пока появится уровень views и интегрирует в него часть логики), тем самым делая приложение излишне сложным.
2. @LaundroMat: «слишком много бизнес-логики в моделях» не может произойти. Большая часть бизнес-логики принадлежит моделям. Проблемы возникают, когда бизнес-логика помещается в шаблоны и виджеты форм.
3. @S. Лотт — Ага, это интересно. Я всегда считал, что модели должны использоваться в разных приложениях и, следовательно, не включать слишком много специфичной для приложения логики. С тем, что вы говорите, я думаю, я могу избавиться от этого чувства беспокойства каждый раз, когда я вводлю сложную логику в модели. Спасибо 🙂
4. @LaundroMat: Модели не являются единицей повторного использования в Django. Приложения — в целом — являются единицей повторного использования.
5. @S.Лотт Когда вы говорите писать тесты в
models.py, я не смог найти никаких источников, в которых говорится, что тесты должны быть где угодно, кроме как в папке tests илиtests.py. Вы бы сказали, что это лучше вmodels.py, а не в каталоге тестов? Я имею в виду ваш первый шаг / инструкцию.
Ответ №2:
Кроме того, в этой серии статей пока есть несколько хороших советов по тестированию приложений django:
http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/
Моя единственная критика в отношении ответа заключалась бы в том, чтобы не хранить все в tests.py файле, а поступать так, как предлагается в статье. Создайте tests каталог и превратите его в модуль, добавив __init__.py файл и импортировав туда все ваши тестовые примеры. например from myapp.tests.views import * . Но, безусловно, разумный совет. Нужно пройти, прежде чем вы сможете запустить… tests ! Видите, что я там сделал?
Комментарии:
1. Хотя мой ранее выбранный лучший ответ был немного более подробным, я думаю, что в вашей статье вы предоставили более четкие рекомендации и помогли мне лучше понять тестирование.
2. Вот еще одно очень подробное руководство по тестированию, которое также охватывает тесты LiveServerTestCase с selenium tdd-django-tutorial.com
Ответ №3:
Я предполагаю, что вы закончили с тестированием приложений Django. С правильным набором вспомогательных инструментов вы должны справляться с модульным тестированием по умолчанию с использованием тестовой платформы Django.
Чтобы начать с измерения покрытия, возможно, вам захочется изучить покрытие standalone, чтобы выяснить, что вы тестировали.
После установки вы можете сделать что-то вроде этого:
$ coverage run manage.py test *yourapp*
Он создаст .coverage файл для вас. Вы можете отформатировать данные из этого файла с помощью
$ coverage report
чтобы получить полный список по тестированию покрытия (включая код из других библиотек python).
Вы можете легко coverage report --omit path создавать модули, которые начинаются с определенных путей. Кроме того, вы сможете увидеть строки, которые не были выполнены во время тестового запуска с -m опцией.
Кроме того, я думаю, что существует django_coverage приложение Django, которое интегрируется coverage в тестирование для проекта Django. Это создает для вас отличные отчеты о покрытии HTML.
Теперь есть другие инструменты, такие как twill и т.д. для удовлетворения конкретных потребностей (например, тестирования javascript).
Кроме того, если вы хотите пройти подробные пошаговые инструкции по настройке ванильного тестирования в Django, вы можете прочитать «Тестирование и отладка Django 1.1» (поиск на Amazon).