Как Вы обрабатываете приложения тестирования, которые в большой степени зависят от баз данных?
На работе мы нашли, что наш набор тестов имеет к точке, вот именно слишком медленной для выполнения неоднократно, который я действительно не люблю. Это - по крайней мере 5 минут по всему комплекту, и более чем 3 минуты для просто тестов объекта данных бэкенда. Так, мне любопытно услышать, как люди делают свое тестирование.
В данный момент у нас есть сервер единой базы данных с живой схемой и _test схемой. Когда тестовые прогоны, это сначала выполняет сценарий SQL, в котором говорится, как заполнить тестовую базу данных (и очистить любые старые данные, которые могли бы помешать). Это происходит почти для всех тестов. Из того, что я вижу, это - самое большое узкое место в наших тестах - я только что представил один тест, и требуется приблизительно 800 мс для установки базы данных и затем каждого последующие тестовые прогоны приблизительно в 10 мс.
Я пытался узнать некоторые решения, и вот то, что я нашел до сих пор:
Заполните тестовую схему однажды и откатывайте изменения в конце каждого теста.
Это, кажется, самое легкое решение, но это действительно означает, что мы оказываемся перед необходимостью добавлять некоторый материал особого случая для тестирования вещей, которые зависят от отката (т.е., тесты обработки ошибок).
Дразните базу данных, если это возможно,
Мы установили бы базу данных для протестированного объекта данных, но дразнили бы что-либо, от чего это зависит. Мне это не кажется блестящим по 2 причинам. Во-первых, когда мы настраиваем базу данных, мы все еще (обычно) заканчиваем с намного большим количеством строк из-за зависимостей внешнего ключа. И во-вторых, большинство моделей объекта данных действительно не взаимодействует с другими, они просто делают СОЕДИНЕНИЯ.
Выполните ту же систему, но используйте дампы и RAMFS
Вместо того, чтобы выполнить большой SQL-запрос мы вместо этого загрузили бы дамп базы данных. Тестовый сервер работал бы на разделе RAMFS и надо надеяться дал бы некоторые преимущества скорости.
Я не могу протестировать это, хотя, потому что я нахожусь на OSX и от того, что я вижу, нет поддержки ramfs.
Существуют некоторые другие опции вокруг подобного использования SQLite, но это не опция для нас, поскольку мы зависим от некоторого PostgreSQL определенные расширения.
Halp!:)
2 ответа
В Эффективная работа с устаревшим кодом Майкл Фезерс пишет (стр. 10)
Модульные тесты выполняются быстро. Если они не работают быстро, это не модульные тесты.
Другие виды тестов часто маскируются под модульные тесты. Тест не является модульным, если:
- Он обращается к базе данных.
- Он обменивается данными по сети.
- Это касается файловой системы.
- Вы должны делать особые вещи в своей среде (например, редактировать файлы конфигурации), чтобы запустить ее.
Тесты, которые делают это, неплохие. Часто их стоит написать, и вы обычно будете писать их с помощью средств модульного тестирования. Однако важно иметь возможность отделить их от настоящих модульных тестов, чтобы вы могли сохранить набор тестов, которые можно было бы быстро запускать всякий раз, когда вы вносите изменения.
Если вы не будете поддерживать быстрые модульные тесты, они потеряют ценность, потому что разработчики не будут запускать их все время. Чтобы быть конкретным, Feathers определяет медленный модульный тест как тест, выполнение которого занимает десятые доли секунды или больше.
Храните ваши интеграционные тесты, которые действительно взаимодействуют с базой данных, касаются файловой системы и т. Д., В своих собственных тестовых наборах, отдельно от ваших модульных тестов. Их по-прежнему нужно запускать как можно чаще, чтобы цикл обратной связи был коротким, но вы можете обходиться им, если выполняете их, скажем, только несколько раз в день.
Не откладывайте свои интеграционные тесты и не забывайте о них! Автоматизируйте их выполнение и отчетность о результатах. Если вы используете сервер непрерывной интеграции, добавьте еще один проект, который ничего не делает, кроме периодического запуска тестов.
В своих модульных тестах используйте имитацию или подделку уровня базы данных.Необходимость повторять одну и ту же работу станет утомительной, а желание избежать этого приведет к улучшению вашего дизайна за счет концентрации доступа к базе данных в нескольких классах и внедрения вашей логики в модель предметной области, а именно в этой области является основой того, что вы хотите протестировать. является.
Интересный вопрос. Судя по тому, что вы пытаетесь выполнить модульное тестирование базы данных, это плохая идея. Вы хотите, чтобы эти тесты были как можно быстрее. Если вы используете уровень данных, вы можете попробовать имитировать его, чтобы он работал в памяти. Протестируйте ложный слой данных.
Не отказывайтесь от текущих тестов, они определенно ценны, и их следует запускать как часть ночной сборки или сборки коммитов из боксов разработчика, где они не замедляются.
Править
Отвечая на ваш комментарий, на самом деле нет хорошего способа ускорить тестирование. Разделение тестов на два набора, один из которых является быстрым для разработчика, а другой - более сложным для непрерывных сборок, вероятно, ваш лучший выбор. Вы можете использовать более быстрое оборудование, SSD или RAM-диски будут хорошим местом для начала.
В дозвуковом проекте (ORM для.net) у нас есть такая же проблема, когда наши тесты занимали бы больше минуты, потому что они должны были воздействовать не только на одну базу данных, но и на экземпляр каждой из баз данных, которые мы в настоящее время поддерживаем. Мы взяли эти тесты и вместо того, чтобы запускать их в базе данных, чтобы увидеть, вернули ли они то, что мы ожидали, мы предположили, что база данных вернет правильные результаты, и просто сравнили строки сгенерированного SQL. Когда мы делаем красно-зеленую разработку, мы просто запускаем модульные тесты сравнения строк. Перед коммитом и на сервере сборки мы запускаем полный пакет.
Отредактируйте второе
Я обнаружил, что мне нужно запустить тесты для базы данных, чтобы подтвердить, что мои запросы верны. Я создал базу данных SQLite в памяти и запустил запросы к ней. Производительность очень хорошая, и он, безусловно, хорошо справляется с моделированием реальной базы данных как таковой.