Продолжение серии постов к выходу новой Django 1.4 (начало, про ORM, про безопасность). Сегодня мы немного осветим фичи в тестовом фреймворке.
Поддержка браузерного тестирования
Docs
Commit 17241
Одна из заметных фич: поддержка интеграционных веб-тестов, например, с помощью Selenium. Он и подобные ему инструменты умеют запускать браузер и выполнять в нём различные действия, имитирующие поведение пользователя на странице, типа кликов по ссылкам, ввода текста в форму и подобного. Это позволяет тестировать сайты вцелом на основе приёмочных тестов (в отличие от юнит-тестов, покрывающих лишь отдельный компонент, но не взаимодействие компонентов). Также, в отличие от тестов с применением привычного django.test.client, Selenium умеет выполнять javascript и вообще ведёт себя как полноценный браузер (а вовсе не headless Client).
Пример такого теста для админки джанги
Раньше примерно то же самое можно было сделать c помощью django-sane-testing или django-selenium. Оба эти варианта обеспечивают более тесную интеграцию с Selenium, в отличие от достаточно абстрактного LiveServerTestCase.
Пока что нормальная интеграция Windmill (альтернативный инструмент для браузерного тестирования) отсутствует, Twill не развивается уже 4 года, но фундамент API заложен.
Кстати, несмотря на то, что у Selenium есть неплохое API для питона, нам больше понравилась надстройка под названием splinter, советуем обратить внимание.
Новые assert-функции и другие улучшения в тестах
Появился упрощенный класс django.test.SimpleTestCase. Он наследует стандартный функционал он unittest.TestCase, снабжая его новым функционалом:
SimpleTestCase
Разновидность unittest.assertRaisesRegexp с той лишь разницей, что expected_message не регулярное выражение.
Поддержка браузерного тестирования
Commit 17241
Одна из заметных фич: поддержка интеграционных веб-тестов, например, с помощью Selenium. Он и подобные ему инструменты умеют запускать браузер и выполнять в нём различные действия, имитирующие поведение пользователя на странице, типа кликов по ссылкам, ввода текста в форму и подобного. Это позволяет тестировать сайты вцелом на основе приёмочных тестов (в отличие от юнит-тестов, покрывающих лишь отдельный компонент, но не взаимодействие компонентов). Также, в отличие от тестов с применением привычного django.test.client, Selenium умеет выполнять javascript и вообще ведёт себя как полноценный браузер (а вовсе не headless Client).
Стал доступен новый класс тестов django.test.LiveServerTestCase, который запускает во время теста встроенный вебсервер на localhost:8081.
Пример такого теста для админки джанги
Раньше примерно то же самое можно было сделать c помощью django-sane-testing или django-selenium. Оба эти варианта обеспечивают более тесную интеграцию с Selenium, в отличие от достаточно абстрактного LiveServerTestCase.
Пока что нормальная интеграция Windmill (альтернативный инструмент для браузерного тестирования) отсутствует, Twill не развивается уже 4 года, но фундамент API заложен.
Кстати, несмотря на то, что у Selenium есть неплохое API для питона, нам больше понравилась надстройка под названием splinter, советуем обратить внимание.
Новые assert-функции и другие улучшения в тестах
Упростились проверки HTML, генерируемого движком, для этого появились функции:
TestCase.assertHTMLEqual(html1, html2, msg=None)
TestCase.assertHTMLNotEqual(html1, html2, msg=None)
Они игнорируют пробельные символы до и после тегов, порядок атрибутов и прочее. Масхэв для интеграционных тестов, где без проверки html порой не обойтись.
assertTemplateUsed и assertTemplateNotUsed теперь можно использовать как контекст-менеджеры.
assertQuerysetEqual обзавёлся аргументом ordered=True, это значит, что теперь можно сравнивать выборки без необходимости задавать сортировку явно.
assertTemplateUsed и assertTemplateNotUsed теперь можно использовать как контекст-менеджеры.
assertQuerysetEqual обзавёлся аргументом ordered=True, это значит, что теперь можно сравнивать выборки без необходимости задавать сортировку явно.
assertRaisesMessage(expected_exception, expected_message, callable_obj=None, *args, **kwargs)
Разновидность unittest.assertRaisesRegexp с той лишь разницей, что expected_message не регулярное выражение.
assertFieldOutput(self, fieldclass, valid, invalid, field_args=None, field_kwargs=None,empty_value=u'')
Проверка того, как ведёт себя поле формы, принимая соответствующие значения.
В примере ниже поле должно принимать 'a@a.com' и отвергать 'aaa'.
self.assertFieldOutput(EmailField, {'a@a.com': 'a@a.com'}, {'aaa': [u'Enter a valid e-mail address.']})
Контекст-процессор TestCase.settings() и декоратор TestCase.override_settings()
Контекст-процессор TestCase.settings() и декоратор TestCase.override_settings()
На время теста можно удобно переопределять определённые настройки прямо из коробки:
@override_settings(LOGIN_URL='/other/login/')
def test_login(self):
response = self.client.get('/sekrit/')
self.assertRedirects(response, '/other/login/?next=/sekrit/')
Ранее подобную задачу мы решали с помощью крайне полезного модуля mock, облегчающего monkey-patching и не только.
To be continued...
Завтра очередная порция, не переключайтесь.
Комментариев нет:
Отправить комментарий