Оверхед… Вместо того, чтобы на уже готовом разворачивать новую базу данных, запускать отдельную виртуалку? Ресурсов будет съедаться значительно выше, да и время на копирование/старт виртуалки будет в разы больше, чем создать временную базу данных и пару таблиц в ней.
Хороший вопрос. Как такого эталонного результата нет. Есть только некоторые характеристики, которым должен отвечать результат выборки.
В качестве примера: если метод должен возвращать непрочитанные сообщения для определенного пользователя, то мы и проверяем в результате, что у объектов свойство IsRead установлено в false, и то, что они принадлежат запрашиваемому пользователю.
А на вход данные генерируются каждый раз.
А как происходит проверка результата работы метода, который ходит в базу? Если я правильно представил процесс, то результат выполнения может варьироваться от запуска к запуску.
и тесты тоже должны симулировать такую вот многопоточность.
Это больше на нагрузочное тестирование похоже.
для меня юнит-тест не имеет права ходить в базу
Да, так и должно быть. У нас они разделены и лежат в разных сборках, одни в *.UnitTests, другие в *.DataBaseIntegrationTests
Я конечно тесты не проводил, и не рассматривал вариант с постгрессом, задачу все-таки было необходимо решить в рамках стека технологий проекта.
За наводку спасибо, заинтересовали. Надо будет как-нибудь побаловаться и провести пару экспериментов.
для некоторых тестов допустимо использовать встраиваемые СУБД (в случае Java, к примеру, H2), но это требует поддержки нескольких СУБД в проекте и плохо увязывается с MySQL (у него крайне не стандартный синтаксис)
Действительно, подобное значительно упростило бы жизнь. На первых парах хотелось поднять sqlite и использовать его в качестве тестовой базы данных, но возможности sqlite достаточны бедны по сравнению с тем, что предоставляет MySQL, так что пришлось отказаться от этой идеи.
Мы одну общую базу используем, больно тестов много, на каждый базу не наразворачиваешься.
Минус такого в том, что тест получается не чистым, т.к. результат может зависеть от выполнения предыдущих тестов. Тем не менее, такой подход тоже используется, например для проверки производительности, когда в тесте важно время выполнения запроса, а не возвращаемые данные. В настройках системы можно указать, чтобы он использовал статичный режим подключения к базе и тогда будет использоваться только одна конкретная база данных для тестирования.
Кстати, а зачем свой генератор данных
Потому что используется своя велосипедная ORM. А так, была рассмотрена похожая система для EntityFramework. Оттуда и черпались лучшие идеи для своего генератора, с некоторыми улучшениями и доработки. Генератор для EF, например, умел генерировать сущности только для одной конкретной таблицы, поэтому приходилось поочередно генерировать данные и потом их связывать. В разработанной системе, все с помощью правил, включая связь по вторичным ключам.
В качестве примера: если метод должен возвращать непрочитанные сообщения для определенного пользователя, то мы и проверяем в результате, что у объектов свойство IsRead установлено в false, и то, что они принадлежат запрашиваемому пользователю.
А на вход данные генерируются каждый раз.
Это больше на нагрузочное тестирование похоже.
Да, так и должно быть. У нас они разделены и лежат в разных сборках, одни в *.UnitTests, другие в *.DataBaseIntegrationTests
За наводку спасибо, заинтересовали. Надо будет как-нибудь побаловаться и провести пару экспериментов.
Действительно, подобное значительно упростило бы жизнь. На первых парах хотелось поднять sqlite и использовать его в качестве тестовой базы данных, но возможности sqlite достаточны бедны по сравнению с тем, что предоставляет MySQL, так что пришлось отказаться от этой идеи.
Минус такого в том, что тест получается не чистым, т.к. результат может зависеть от выполнения предыдущих тестов. Тем не менее, такой подход тоже используется, например для проверки производительности, когда в тесте важно время выполнения запроса, а не возвращаемые данные. В настройках системы можно указать, чтобы он использовал статичный режим подключения к базе и тогда будет использоваться только одна конкретная база данных для тестирования.
Потому что используется своя велосипедная ORM. А так, была рассмотрена похожая система для EntityFramework. Оттуда и черпались лучшие идеи для своего генератора, с некоторыми улучшениями и доработки. Генератор для EF, например, умел генерировать сущности только для одной конкретной таблицы, поэтому приходилось поочередно генерировать данные и потом их связывать. В разработанной системе, все с помощью правил, включая связь по вторичным ключам.