На крупном веб-проекте есть разработческая среда (dev), которая смотрит в базы, наполненные срезом данных с живой среды.
Есть вторая разработческая среда (stage), которая смотрит в живые базы, кеши и пр.
Внимание вопрос:
Под какую среду писать тесты?
В dev среде данные уже достаточно старые, перетаскивать регулярно с живого — очень сложно, нужно носить террабайты данных в сотни разных баз. Кроме того, из-за масштабов, тестовую среду чертовски сложно поддерживать: достаточно часто где-нибудь что-нибудь да отвалится.
В stage среде все более менее хорошо. Данные актуальные, работать с ними просто. Но есть одно важное НО: у разработчиков есть доступ только на dev среду (по соображениям безопасности). Для раскладки проекта в stage, необходимо запускать специальный раскладчик, который работает в пределах минуты. То есть приходиться коммитить, запускать раскладчик и видеть свой код, смотрящий на живой. Это крайне утомительно.
Хочется писать тесты, но под какую среду? Для dev часто не хватает актуальности данных (лучшие данные — актуальные), чтобы гонять тесты на stage, нужно коммитить, раскладывать и пр. — утомительно.
Как решаете проблему вы? Предложите решение для данной ситуации?
Вы уверены что для прогона тестов Вам нужна живая база (срез и т.п.)?
Общепринятый подход в том что тестовая база это отдельная база (да и среда отдельная) для которой данные заполняются с помощью генераторов (factory_girl например). В тестах каждый отдельно взятый тест обораичвается в транзакцию с роллбеком в конце для автоматического очищения. При этом справочные таблицы часто заливают заранее.
Если возникает баг который проявляется с определенным набором данных, то он воспроизводится в тестах с нужными данными.
Как один из вариантов (подходящий не во всех случаях) — делать время от времени lvm snapshot основной базы для разработчиков. Можно даже snapshot реплицированной копии.
Вы еще не бекапите? :)
Количество и объем ни о чем не говорят — скрипту все равно сколько лопатить.
У меня dev просто поднимает последний backup с production — заодно проверяется его целостность.
Как вариант, создать крон который каждые Х минут будет раскладчик, а после окончания его работы прогонять тесты. И отправлять себе на ящик емейл для отвалившихся тестов. Т.е. комитнули, дальше работаем, через некоторое время приходит почта, смотрим что там (или потом смотрим, когда время будет).
Это все понятно, хадсон уже есть) Он делает сборку, как только видит изменение в ветке testing и потом гоняет тесты. Но вот, какие данные выбирать для тестов, чтобы они с одной стороны не изменялись, а с другой были в актуальном состоянии — это вопрос.
я бы порекомендовал настроить a dev среду по феншую. А то покрывать тестами полу-рабочий функционал понятное дело будет тяжело.
Помнится когда переводили с м на т одну из баз в одном из демонов, чтобы поработать с данными на тестовом окружении с нужной базой пришлось ждать когда она перельется с живого, вместо того чтобы получить ссыль с рабочим кодом который позволил бы мне забить самому данные для тестов или же вызвать тестоскрипт — который бы налил этак сотенку новых псевдо-рандомных записей автоматом, а заодно бы проверил нормальную работу создания новых записей в базе на тестовом окружении.
Простой
Простой
