Модульное тестирование уровня DAO с базой данных H2

Question

После долгих чтений в интернете я обнаружил, что хорошей практикой является использование БД в памяти, такой как H2, для модульного тестирования уровня DAO. Идея заключается в том, чтобы избежать работы с производственной БД.

Отлично, поэтому я настроил базу данных H2 и активировал режим совместимости с H2 PostgreSQL, так как моя рабочая база данных находится на Postgres. Проблема, с которой я сейчас сталкиваюсь: когда я запускаю на H2 исходные запросы SQL для создания тестовой БД, этот запрос не считается действительным для H2:

ALTER SEQUENCE MYERP.ecriture_comptable_id_seq OWNED BY MYERP.ecriture_comptable.id;

Я предполагаю, что использование режима совместимости с PostgreSQL не является гарантией того, что весь специфический синтаксис Postgres будет принят H2. И, вероятно, это также произойдет с другими БД, такими как MySQL.

Так какой смысл в этом случае использовать базу данных h2? Я что-то пропустил?

Answer 1

Модульное тестирование должно быть сосредоточено на тестировании юнитов. PostgreSQL является внешним по отношению к вашему приложению и, таким образом, тривиально не является частью какого-либо DAO, который его использует: не следует писать «модульный тест», который использует любую такую ​​внешнюю базу данных.

Использование базы данных для интеграционных тестов может быть нормальным, но, как вы уже заметили, могут возникнуть многочисленные проблемы, когда вы используете другую базу данных для выполнения интеграционных тестов (я знаю очень мало приложений, которые используют только ANSI-SQL без каких-либо триггеров или других поставщиков). конкретные расширения SQL, такие как UPSERT в случае PostgreSQL или SQL в вашем сообщении.

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