Каков наилучший подход для написания модульных тестов для кода, который сохраняет данные в хранилище данных nosql, в нашем случае cassandra?
= > Мы используем встроенный серверный подход, используя утилиту из git hub (https://github.com/hector-client/hector/blob/master/test/src/main/java/me/prettyprint/hector/testutils/EmbeddedServerHelper.java). Однако я видел некоторые проблемы с этим. 1) Он сохраняет данные в нескольких тестовых случаях, что затрудняет нам проверку данных в тестовых примерах тестового класса. Я попытался вызвать cleanUp @После каждого тестового примера, но это не похоже на очистку данных. 2) У нас заканчивается память, так как мы добавляем больше тестов, и это может быть из-за 1, но я пока не уверен в этом. У меня в настоящее время размер кучи 1G для запуска моей сборки.
= > Другой подход, о котором я думал, состоит в том, чтобы издеваться над хранилищем cassandra. Но это может привести к утечке некоторых проблем в схеме cassandra, поскольку мы часто находили, что вышеупомянутый подход ловит проблемы с тем, как данные хранятся в cassandra.
Пожалуйста, дайте мне знать ваши мысли об этом, и если кто-то использовал EmbeddedServerHelper и знакомы с проблемами, о которых я упоминал.
Просто обновление. Я смог решить 2) исчерпание проблемы с кучей java-пространства при запуске сборки путем изменения параметра in_memory_compaction_limit_in_mb до 32 в файле cassandra.yaml, используемом встроенным сервером тестирования. Следующая ссылка помогла мне http://www.datastax.com/docs/0.7/configuration/storage_configuration#in-memory-compaction-limit-in-mb. Это было 64 года, и он начал неуспешно во время уплотнения.