Я не знаю о тестировании для MongoDB, но вот что я делаю для PostgreSQL.
Я следую шаблону при разработке баз данных, которые отделяют сторону БД от стороны приложения. Для тестирования стороны БД у меня есть тестовая схема, которая включает в себя одну хранимую процедуру, которая сбрасывает все данные в реальной схеме. Этот сброс выполняется по шаблону MERGE (удалите все записи с нераспознанным ключом, обновите записи, которые имеют совпадающие ключи, но которые изменены, и вставьте отсутствующие записи). Этот сброс вызывается перед выполнением каждого модульного теста. Это дает мне простое и понятное тестовое покрытие для сохраненных функций.
Для тестирования кода, вызывающего вызовы в базу данных, слой базы данных всегда моделируется, поэтому никогда не будет каких-либо вызовов , которые действительно идут в базу данных.
То, что вы описываете, подсказывает мне, что вы пытаетесь смешать модульное тестирование с интеграционным тестированием, и я настоятельно рекомендую вам не делать этого. Интеграционное тестирование - это то, что происходит, когда вы уже доказали базовую функциональность и хотите доказать интеграцию между компонентами и, возможно, также и производительность. Для ИТ вам действительно нужен репрезентативный набор данных на репрезентативном оборудовании. Обычно это означает выделенную машину и использование Hudson для CI.
Направление, в котором вы, кажется, движетесь, будет трудным, потому что, как вы уже заметили, трудно обрабатывать этот объем данных и сложно создавать репрезентативные наборы данных (большинство систем CI фактически используют производственные данные, которые был "очищен" от конфиденциальной информации)
Именно поэтому большинство мест, где я работал, не пошли по этому пути.