Должны ли тесты перед фиксацией использовать большой набор данных и терпеть неудачу, если запросы занимают слишком много времени, или использовать небольшую тестовую базу данных?

Я разрабатываю несколько модулей Python, которые используют базу данных mysql для вставки некоторых данных и создания различных типов отчетов. Я занимаюсь разработкой через тестирование и пока что бегаю:

  • некоторые тесты CREATE / UPDATE / DELETE для временной базы данных, которая отбрасывается в конце каждого тестового примера, и
  • некоторые тесты генерации отчетов, выполняющие исключительно операции только для чтения, в основном SELECT, с копией производственной базы данных, написанной с (действительным, в данном случае) предположением, что некоторые вещи в моей базе данных не изменятся.

Некоторые операции SELECT выполняются медленно, поэтому мои тесты занимают более 30 секунд, что портит процесс разработки через тестирование. Я вижу два варианта:

  1. помещаю только небольшую часть моих данных в копию производственной базы данных, которую я использую для тестирования генерации отчетов, чтобы тесты проходили достаточно быстро для разработки, управляемой тестами (мне лучше всего подходит менее 3 секунд), или я могу рассмотреть тесты как отказы. Затем мне нужно будет провести отдельное тестирование производительности.
  2. заполните копию производственной базы данных таким же количеством данных, как и в основной тестовой базе данных, и добавьте код синхронизации, который не проходит тест, если он длится слишком долго.

Я не уверен, какой подход выбрать. Любой совет?


python mysql sql automated-tests tdd
person Dickon Reed    schedule 16.02.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я бы сделал и то, и другое. Сначала запустите небольшой набор, чтобы убедиться, что весь код работает, затем запустите большой набор данных для вещей, которые необходимо проверить на время, особенно это будут выборки, поиск и отчеты. Если вы выполняете вставку, удаление или обновление для нескольких наборов строк, я бы протестировал их также на большом наборе. Маловероятно, что простые однострочные запросы действий займут слишком много времени, но если они включают много соединений, я бы тоже их протестировал. Если запросы не будут выполняться на продукте в пределах тайм-аута, это будет неудачей и далеко, гораздо лучше узнать как можно скорее, чтобы вы могли исправить, прежде чем ставить prod на колени.

person HLGEM    schedule 16.02.2010

arrow_upward
1
arrow_downward

Проблема с тестированием на реальных данных заключается в том, что оно содержит много повторяющихся значений и недостаточно крайних случаев. Также трудно понять, какими должны быть ожидаемые значения (особенно если ваша действующая база данных очень большая). Да, и в зависимости от того, что делает живое приложение, использование данных в целях тестирования или разработки может быть незаконным.

Как правило, лучше всего записывать тестовые данные вместе с тестами. Это утомительно и скучно, поэтому многие практикующие TDD ненавидят базы данных. Но если у вас есть набор данных в реальном времени (который вы можете использовать для тестирования), возьмите очень урезанный набор данных для ваших тестов. Если вы можете написать действительные утверждения для набора данных из тридцати записей, запуск ваших тестов для набора данных из тридцати тысяч - просто пустая трата времени.

Но определенно, как только вы получите запросы, возвращающие правильные результаты, проведите их через некоторые тесты производительности.

person APC    schedule 16.02.2010