Вот сканарио:
Я работаю над объектом DAO, который использует API критериев гибернации для формирования ряда сложных запросов для выполнения определенных задач в базе данных (например, поиск по ключевым словам по нескольким полям).
Нам нужно провести модульное тестирование, чтобы убедиться, что сгенерированный запрос корректен для различных сценариев. Один из способов его проверки, который может быть предпочтительнее, состоит в том, чтобы проверить правильность создания критериев гибернации, проверив его в конце и смоделировав взаимодействие с базой данных. Однако это нежелательно, так как, во-первых, это своего рода обман (просто дублирование того, что будет делать код), а также он не проверяет, вызывают ли сами критерии спящий режим для рвоты или когда он переходит в базу данных, это вызывает проблемы.
Затем можно использовать вариант запуска запроса к тестовой базе данных. Однако по историческим причинам не существует статической тестовой базы данных (например, такой, в которой код может быть проверен как часть кода), и задача моего проекта не позволяет мне приступить к ее созданию, мы должны довольствоваться тестированием на основе общая база данных разработки, которая периодически обновляется производственными данными.
Когда происходят эти обновления, данные, лежащие в основе тестов, также могут измениться, и это сделает наши модульные тесты хрупкими. Мы можем преодолеть это, не используя точные числа в тестах, но это не совсем адекватное тестирование.
Тогда возникает вопрос: что люди делают в таких случаях, чтобы сделать тесты менее хрупкими? Один из вариантов, который я имею в виду, - запустить собственный SQL, который выполняет тот же запрос (поведенчески - он не обязательно должен быть точно таким же, как запрос, сгенерированный спящим режимом), чтобы получить ожидаемое число, а затем запустить версию DAO, чтобы увидеть если совпадает. Таким образом, поведение запроса всегда может быть реализовано в исходном собственном SQL, и у вас всегда будут правильные числа.
Будем очень признательны за любые отзывы об этой или других идеях о том, как справиться с этой ситуацией.
A.
ОБНОВЛЕНИЕ:
Что касается предложений hsqldb/h2/derby, я знаком с ними, но компания пока не готова пойти по этому пути, и делать это по частям только на одном тестовом примере будет нецелесообразно.
Что касается моего более раннего предложения, я хотел бы немного подробнее остановиться на этом сценарии:
Я хочу убедиться, что мой относительно сложный поиск по ключевым словам возвращает 2100 совпадений для «Джона Смита».
Чтобы найти ожидаемое число, я бы проанализировал свою базу данных и узнал число с помощью SQL-запроса. В чем недостаток того, что этот запрос является частью теста, чтобы вы всегда знали, что тестируете поведение критериев?
Итак, в основном вопрос таков: если по какой-то причине у вас не может быть статического набора данных для тестирования, как бы вы выполнили интеграционные тесты без ошибок?
