в функциональных тестах с большим покрытием кода? в каждом куске кода, который такой тест покрывает потенциально может быть ошибка, если код знаешь с нуля, то да все найдется быстро, если в проект пришел через код его существования, то все тонкости не будешь знать…
с юнит тестами да все просто — но на то они и юнит…
> Про быстрый SQLite в памяти можно забыть, в проекте есть привязки к особенностям postgres, да и идентичность тестового окружения все-таки важна, поэтому тесты тоже работают на postgres.
то так нельзя запустить тесты нескольким пользователям с базой на одном серваке… т.к. все базы у первого попытаются грохнуть Runner второго…
Ну и зря убрали REUSE_DB, я про это в статье писал, запуск одного отдельного теста должен быть 1-2 секунды, а не даже 10-20сек, а создание базы может занять и больше времени…
у нас много внешних зависимостей: шлюзы оплаты, провайдеры, просто какие-то внешние сервисы с апи… это все нужно мокать — мы мокаем… И для этого обвертка mock_http, чтоб разработчики понимали, что тест стучится во внешний мир…
У нас был момент, когда мы использовали только уникальную базу, а когда подключали транзакции, то часть тестов не работали в транзакции и почему было не очевидно :)… Поэтому те которые не работали оставили с уникальной базой. В общем пока точно не знаю, предстоит разобраться… :)
1. setup_databases пишем под себя, написал об этом в шапке раннера
2. да про редис забыл :), для зачистки обвертка…
3. mock_http — тесты не должны сутчатся на внешний http, т.к. он может отвалиться или сети вообще не быть, а тесты должны ходить в не зависимости, отвечает сайт или нет. Поэтому мы мокаем http запросы. mock_http нужен, чтоб видеть что тест делает http и свалиться, в трейсбеке можно увидеть, где возник этот запрос — потом идем мокаем :)… так же можно запустить с ключем --without-mock-http :)
sql — дамп нужно также поддерживать, как и статические фикстуры, что тут другого?
В setup_databases(это из gist) можно все что угодно сделать с базой, в том числе и подтянуть sql дамп с диска, или прям строкой записать в базу тригер — это не важно.
Потом между тестами мы ее будем создавать с WITH TEMPLATE (мы ведь про postgres) и там у нас будут уже все тригиры и данные, которые мы туда запихнем на шаге создания бд… Эта операция (создание бд с WITH TEMPLATE) быстрее чем flush на большой базе, но медленее транзакций. Про это в статье говориться.
в приципе там особо привязок нет, я немного обновил gist, добавил requirements.txt и пару коментов. У нас это пакет, поэтому нужно его создать… Но для публикации идеи мне казалось gist-a достаточно…
у меня опыт интенсивного TDD в python уже пару лет точно — это осознанный выбор, с учетом опыта…
Да покрытие кода не говорит про качество тестов, но я описал плюс покрытия кода для питона.
Нужно писать хорошие тесты, как и нужно писать хороший код :).
Если поверх WSGI трудно тестировать какую-то логику, нужно спускаться ниже, и ниже уже проверять тонкую логику (например: на джанго форме или моделе) — это уже ближе к юнит тестам…
Тест поверх WSGI все равно нужен — он проверит код в реальном воркфлоу :), пусть даже не со всей логикой.
кстати www.heroku.com/ тоже поддерживает python. Один вебпроцес, шаред posgresql, 200 писем в день через sendgrid.com(интегрирован как аддон) бесплатно, деплой через git push :)
с юнит тестами да все просто — но на то они и юнит…
:) критичен
TEST_DB_PREFIX = settings.DATABASES['default']['NAME'] + '__'
то так нельзя запустить тесты нескольким пользователям с базой на одном серваке… т.к. все базы у первого попытаются грохнуть Runner второго…
Ну и зря убрали REUSE_DB, я про это в статье писал, запуск одного отдельного теста должен быть 1-2 секунды, а не даже 10-20сек, а создание базы может занять и больше времени…
у нас много внешних зависимостей: шлюзы оплаты, провайдеры, просто какие-то внешние сервисы с апи… это все нужно мокать — мы мокаем… И для этого обвертка
mock_http, чтоб разработчики понимали, что тест стучится во внешний мир…там данные, которые похожи на прод и их там много, на них проверяем миграции…
Нет не под каждый бранч :), одна на все бренчи — но это отдельная история :)
django_noseиnoseтак понимаю, то наследникDjangoTestSuiteRunner+ свойTestCaseсо всей логикой из плагинов— при кажой миграции схемы, нужно переливать дамп
— одновременное редактирование схемы — что тогда, делать мердж будет напряжно?
у нас большая достаточно команда, гит и куча бранчей, тестовая база — дамп на 5 гиг :)… Все не так-то просто :)
setup_databasesпишем под себя, написал об этом в шапке раннера2. да про редис забыл :), для зачистки обвертка…
3.
mock_http— тесты не должны сутчатся на внешний http, т.к. он может отвалиться или сети вообще не быть, а тесты должны ходить в не зависимости, отвечает сайт или нет. Поэтому мы мокаем http запросы.mock_httpнужен, чтоб видеть что тест делает http и свалиться, в трейсбеке можно увидеть, где возник этот запрос — потом идем мокаем :)… так же можно запустить с ключем--without-mock-http:)ок, согласен gist заточен под проект :)
В
setup_databases(это из gist) можно все что угодно сделать с базой, в том числе и подтянуть sql дамп с диска, или прям строкой записать в базу тригер — это не важно.Потом между тестами мы ее будем создавать с
WITH TEMPLATE(мы ведь про postgres) и там у нас будут уже все тригиры и данные, которые мы туда запихнем на шаге создания бд… Эта операция (создание бд сWITH TEMPLATE) быстрее чемflushна большой базе, но медленее транзакций. Про это в статье говориться.Про pytest вкурсе, даже про распределенность его читал, но как-то все больше именно nose становиться в качестве основного пускальщика.
Нужно еще посмотреть повнимательнее.
Да покрытие кода не говорит про качество тестов, но я описал плюс покрытия кода для питона.
Нужно писать хорошие тесты, как и нужно писать хороший код :).
Если поверх WSGI трудно тестировать какую-то логику, нужно спускаться ниже, и ниже уже проверять тонкую логику (например: на джанго форме или моделе) — это уже ближе к юнит тестам…
Тест поверх WSGI все равно нужен — он проверит код в реальном воркфлоу :), пусть даже не со всей логикой.
./manage.py test— база создается :)между тестами да обычно транзакции, но может быть и flush — в статье это опоминалось…
сравнивается 3 подхода: make, fabric, pure python
еще есть python-doit.sourceforge.net/ paver.github.com/paver/ из той же темы.