Тестирование набора данных, возвращенных из базы данных

Question

Если я тестирую набор строк базы данных, по каким критериям можно проверять?

Должен ли я проверить, что существует строка с именем A, и т. Д. (Что находится в базе данных)? Это плохая идея? Этот тип теста является хрупким, поскольку данные могут изменяться, но запрос может быть правильным.

Имея это в виду, было бы лучше проверить имена столбцов, которые я вернул в наборе данных? Вот так (/540473/poluchit-imena-stolbtsov-iz-java-sql-resultset).

Спасибо

Answer 1

Вам не нужно ничего тестировать с базой данных, за исключением того, что база данных и код работают.

Итак, используя базу данных, созданную в тестовой среде, подключите код, который используетбазы данных и проверьте, что он делает все, что должен.

Помните, что в тесте очень редко вам нужно проверять, как что-то делается, а вы должны тестировать эту купольную штукудействительно ли это сделано.

Например, если вы используете hibernate для сохранения ваших сущностей, вы можете иметь тест под названием canRoundTripAFooBar, который сохраняет foobar, загружает его снова и сравнивает каждое поле, чтобы убедиться, чтотот, который вы загрузили, и тот, который вы сохранили, одинаковы (за исключением тех битов, которые не должны быть одинаковыми, таких как идентификаторы или что-то в этом роде)

Answer 2

Не проверяйте, что находится в базе данных.Просто приведите несколько примеров того, как ваша система предоставляет значение.

Если значение действительно находится в базе данных - например, другая служба использует эти данные - затем опишите, что ваша система предоставляет в терминах этого значения.Например:

• Моя система может сохранить пользователя с его семьей из четырех детей и супругом в другой стране.
• Моя система может обрабатывать японские адреса.
• Моя система может предоставить исторические данные о ценах.

Если вам действительно нужно, вы можете затем связать большие порции данных, а не отдельные строки, с концепциями домена, которым они соответствуют.Удаление некоторого дублирования - например, помещение его в пользовательские тестовые запросы - поможет сохранить его менее хрупким.

Если вы можете вспомнить примеры того, что предоставляет ваша система, вы, вероятно, сможете охватить все данные.он также предоставляет.

Еще один способ сделать тесты еще менее хрупкими - это использовать свой уровень персистентности или уровень персистентности системы, которую вы обслуживаете (например, Hibernate), для преобразования данных обратно в объекты домена.которые имеют больше смысла для этих примеров.

Это также поможет вам проверить, что данные, которые вы предоставляете, действительно ценны, а не просто там .Если вы используете свою собственную систему, вы можете сделать это и сохранить полную свободу в отношении формата, используемого для хранения данных.Вы также можете делать такие вещи, как:

• Моя система не позволяет мне хранить детей без родителя.
• Моя система не допускает адреса с более чем 150 символами в строке.

и проверка исключений базы данных, что также позволяет проверять ограничения.

Answer 3

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

Проверка имен столбцов? Почему это изменится? Надеюсь, разработчики не вносят изменения в производственный сервер?

То, что вы, вероятно, хотите, это как часть процесса сборки CI для полного развертывания ваших баз данных (применения всех сценариев инкрементных изменений [у вас есть такие?)) На тестовом сервере.