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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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