Лучшие практики для получения наибольшего количества тестируемого покрытия с Django / Python? - PullRequest
16 голосов
/ 05 мая 2011

Моих тестов серьезно не хватает, и я не очень верю в них.Каковы некоторые из лучших практик для получения максимального охвата тестирования, который я могу использовать с помощью Django / Python?Я смотрел на Освежающий и Салат , которые выглядят довольно многообещающе, но я не могу использовать их для всего , могу я?Я ищу совет о том, как структурировать мой рабочий процесс / проект с помощью тестирования, чтобы я мог чувствовать себя уверенно при развертывании нового кода в производственной среде.

Ответы [ 3 ]

33 голосов
/ 05 мая 2011
  1. Прекратить кодирование.

  2. Напишите тесты для того, что должно делать ваше приложение.

Сначала используйте встроенное тестирование Django. Напишите тесты моделей в виде классов TestCase внутри вашего models.py.

Сделай это сейчас. Прежде чем читать дальше. Прямо сейчас добавьте django.test.TestCase классы, которые создают, изменяют и извлекают объекты модели. Убедитесь, что у вас есть метод теста для каждого свойства, атрибута или дополнительного метода, который вы определили.

Я подожду, пока ты не закончишь это.


Модельные испытания завершены? Хорошо.

Теперь создайте файл tests.py в каждом приложении. Каждый из. Все пусто.

В каждом файле tests.py создайте django.test.TestCase классов для каждой формы.

Сделай это сейчас. Создайте хорошие и плохие формы. Создайте формы с каждой отдельной проблемой проверки полей.

Не создавайте все возможные варианты неверных данных. Всего один контрольный пример для каждого отдельного правила проверки.

Сделай это сейчас. Прежде чем читать дальше. Добавьте django.test.TestCase классов в tests.py для каждой формы.

Я подожду, пока ты не закончишь это.


Теперь вам нужно проверить каждую функцию просмотра. Они также идут в файле tests.py. У каждой функции просмотра есть как минимум два тестовых примера, возможно, больше, в зависимости от того, какие декораторы вы используете.

Если функция просмотра требует входа в систему, у вас есть два случая: войти в систему и не войти в систему.

Если функция просмотра требует разрешения, у вас есть по крайней мере три случая: не вошли в систему, вошли как неправильный пользователь, вошли в систему как правильный пользователь.

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

Сделай это сейчас. Прежде чем читать дальше. Добавьте django.test.TestCase классы в tests.py для каждой функции представления.

Я подожду, пока ты не закончишь это.


Это тесты, которые вы должны написать сначала перед написанием кода приложения.

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

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

10 голосов
/ 06 мая 2011

Кроме того, в этой серии статей есть несколько полезных советов по тестированию приложений django:

http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/

Моя единственная критика ответа будет заключаться в том, чтобы не хранить все в tests.py файл, но делайте так, как предлагает статья.Создайте каталог tests и включите его в модуль, добавив файл __init__.py и импортировав туда все свои тесты.например, from myapp.tests.views import *.Но, безусловно, здравый совет.Должен идти, прежде чем ты сможешь бежать ... tests!Видишь, что я там делал?

7 голосов
/ 05 мая 2011

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

Чтобы начать с измерения покрытия, вы можете изучить покрытие в автономном режиме, чтобы выяснить, что вы тестировали.

После установки вы можете сделать что-то вроде этого:

$ coverage run manage.py test *yourapp*

Он создаст для вас файл .coverage. Вы можете отформатировать данные из этого файла с помощью

$ coverage report

, чтобы получить полный список тестируемого покрытия (включая код из других библиотек python). Вы можете легко coverage report --omit path модули, которые начинаются с определенных путей. Кроме того, вы сможете увидеть строки, которые не были выполнены во время теста с опцией -m.

Кроме того, я думаю, что есть приложение django_coverage Django, которое интегрирует coverage в тестирование проекта Django. Это делает хорошие отчеты о покрытии HTML для вас.

Теперь есть другие инструменты, такие как твил и т. Д. Для решения конкретных задач (например, тестирование JavaScript).

Также, если вы хотите пройти детальные шаги по настройке тестирования ванили под Django, вы можете прочитать «Django 1.1 Testing and Debugging» (поиск на Amazon).

...