#python #django #testing #tdd
#python #django #тестирование #tdd
Вопрос:
В настоящее время я использую один файл fixtures для каждого приложения, но по мере роста проектов тесты занимают слишком много времени, и я считаю, что (теперь большие) приспособления, загружаемые для каждого тестового класса, являются ошибкой.
Я избегал большого количества небольших приспособлений из-за опасений по поводу дублирования и обслуживания, но я знаю, что это неизбежно.
Однако, прежде чем я пойду по этому пути, я подумал, что хотел бы спросить, что другие делают с приборами для тестирования своих приложений / проектов.
Ответ №1:
Да, вы столкнулись с проблемой с большим набором приспособлений. Постоянная десериализация / загрузка увеличивается по мере роста вашего набора тестов. Я бы предложил написать служебные функции для создания данных по мере необходимости, а не полагаться на приспособления. Например, у вас может быть функция для создания нового auth.User
подобного:
def create_user(data=None):
data = data or {}
defaults = {
'username': get_random_string(),
'email': get_random_email(),
'password': get_random_string()
}
defaults.update(data)
return User.objects.create_user(**defaults)
Написание функции для генерации случайной строки / электронной почты оставлено в качестве упражнения для читателя 🙂
Ответ №2:
Убедитесь, что вы используете sqlite для целей тестирования. Существует значительная разница в скорости по сравнению с другими движками БД.
Комментарии:
1. Это быстрее, потому что не проверяет какие-либо данные, которые вы вводите.
2. @Mark, ваша точка зрения о проверке данных в большинстве случаев не имеет значения при работе с django. Тесты с sqlite выполняются
tremendously
быстрее, потому что sqlite работает в памяти. Можно настроить параметры django так, чтобы mysql или postrges использовали таблицы в памяти вместо обычных, если вы это сделаете, то между базами данных не будет существенной разницы.3. Цель написания тестов не в том, чтобы иметь быстрый набор тестов; это убедиться, что ваш код выполняет то, что должен, когда вы переносите его в рабочую среду, где вы не должны использовать Sqlite. Тривиально писать код на Django и последующие тестовые примеры, которые будут передаваться на Sqlite и завершаться сбоем в реальной базе данных. Вы не делаете себе никаких одолжений, используя Sqlite для тестирования.