То, что вы делаете, - это переход от «все работают вместе в одной среде» к «у каждого своя среда разработки».Основное преимущество заключается в том, что все не будут наступать друг другу на ноги.
Другие преимущества включают гетерогенную среду разработки, то есть, если все будут разрабатывать на одной машине, программное обеспечение станет зависимым от этой единой установки, поскольку разработчикиленивыЕсли все будут разрабатывать в разных средах, даже просто с немного разными версиями одного и того же материала, они будут вынуждены написать более надежный код, чтобы справиться с этим.
Главный недостаток, как вы заметили, заключается в том, чтонастройка среды сложнее.В частности, убедитесь, что база данных работает.
Во-первых, у каждого разработчика должна быть своя собственная база данных.Это не означает, что у них всех должна быть своя собственная база данных сервер (хотя это хорошо для разнородных целей), но у них должен быть свой собственный экземпляр базы данных, который они контролируют.
Во-вторых, вам следует имеет схему , а не только то, что находится в базе данных.Он должен находиться в файле с управлением версиями.
В-третьих, установка новой базы данных должна выполняться автоматически.Это позволяет разработчикам без проблем создавать чистую базу данных.
В-четвертых, вам необходимо получить интересные тестовые данные в эту базу данных.Вот где все становится интересным ...
У вас есть несколько способов сделать это.
Сначала необходимо создать дамп существующей базы данных, которая содержит реалистичные данные, конечно же, санированные.Это легко и дает реалистичные данные, но это очень хрупко.Разработчики должны будут искать интересные данные для тестирования.Эти данные могут измениться в следующем дампе, нарушив их тесты.Или он может вообще не существовать.
Второе - написать «тестовые данные».По сути, каждый тест заполняет базу данных необходимыми данными теста.Преимущество этого состоит в том, что разработчик может получать именно те данные, которые ему нужны, и точно знать, в каком состоянии находится база данных. Недостатки заключаются в том, что она может занимать очень много времени, и часто данные слишком чисты ,Данные не будут содержать все грубые реальные данные, которые могут вызвать реальные ошибки.
В-третьих, вообще не обращайтесь к базе данных, а вместо этого «имитируйте» все вызовы базы данных.Вы обманываете все методы, которые обычно запрашивают базу данных, вместо этого возвращая данные тестирования.Это очень похоже на написание тестовых приборов и имеет большинство тех же недостатков и преимуществ, но это гораздо более инвазивно.Это будет трудно сделать, если ваша система не предназначена для этого.Кроме того, он никогда не проверяет, работает ли ваша база данных.
Наконец, вы можете создать набор библиотек, которые генерируют для вас полуслучайные данные.Я называю это «Техникой симов» после видеоигры, в которой вы создаете поддельные семьи, мучаете их, а затем выбрасываете их.Например, допустим, у вас есть объект User, которому нужно имя, возраст, объект Payment и объект Session.Чтобы протестировать пользователя, вам могут потребоваться пользователи с разными именами, возрастами, способностью платить и статусом входа.Чтобы контролировать все, что вам нужно, генерировать тестовые данные для имен, возрастов, платежей и сессий.Итак, вы пишете функцию для генерации имен и одну для генерации возрастов.Это может быть так же просто, как случайный выбор из списка.Затем вы пишете один, чтобы сделать вас объектом платежа, а другой - объектом сеанса.По умолчанию все атрибуты будут случайными, но действительными ... если не указано иное.Например ...
# Generate a random login session, but guarantee that it's logged in.
session = Session.sim( logged_in = true )
Тогда вы можете использовать это, чтобы собрать интересного пользователя.
# A user who is logged in but has an invalid Visa card
# Their name and age will be random but valid
user = User.sim(
session = Session.sim( logged_in = true ),
payment = Payment.sim( invalid = true, type = "Visa" ),
);
В этом есть все преимущества тестовых приспособлений, но, поскольку некоторые данные непредсказуемы, у них есть некоторые преимущества реальных данных. Добавление «интересных» данных в функции по умолчанию для sim и rand будет иметь широкий спектр последствий. Например, добавление имени Unicode к random_name, вероятно, обнаружит все виды интересных ошибок! К сожалению, это дорого и требует много времени.
Вот, пожалуйста. К сожалению, нет простого ответа на проблему с базой данных, но я умоляю вас не просто копировать производственную базу данных, так как в конечном итоге это проигрышное предложение. Вы, скорее всего, сделаете гибрид из всех вариантов: копирование, фикстуры, насмешки, полуслучайные данные.