Возможная последовательность и тестовые случаи

Question

Каков наилучший способ написания тестовых случаев при работе с в конечном итоге непротиворечивым хранилищем данных, таким как MongoDB?

Моя текущая настройка - Mongodb с настройкой Master / Slave / Slave с 3 узлами, для slave-ok установлено значение true. Это означает, что главный узел используется только для записи, а два подчиненных узла - только для чтения.

Время, необходимое для согласованности данных на ведомых устройствах, относительно мало и зависит от операции и размера данных. Например, ~ 3 мс для операций удаления и ~ 200 мс для пакетной вставки из 1000 объектов.

Моя цель - протестировать операции на моем Дао. Они могут быть простыми, такими как getById, delete, insert, или сложными, как findByExample. Мне нужно убедиться, что они работают правильно, и в конечном итоге допустимо некоторое ограничение времени ожидания.

Это то, что у меня есть, чтобы проверить операцию удаления, например:

  @Test
  public void deleteTest() throws InstantiationException,
              IllegalAccessException {
        MyObject obj = new MyObject();
        obj.setName("test object");
        obj.save(obj);
        MyObject found = dao.findById(obj.getId());
        logger.info ("before: " + found);
        Assert.assertEquals(obj, found);

        dao.delete(obj.getId());
        MyObject deleted = null;
        long start = System.nanoTime();
        do {
              //TBD: need to add escape condition/timeout, else may be infinite loop....
              deleted = dao.findById(obj.getId());
              logger.info ("While: " + deleted);
        } while (deleted!=null);
        logger.info("It took " + ((System.nanoTime()-start)/1000000.00) + " ms for delete to be consistent");
        Assert.assertEquals(null, d1);
  } 

Answer 1

Что бы вы ни делали, вы можете положиться на тот факт, что с набором реплик mongo всегда будет писать мастеру.Поэтому я бы изменил тест удаления на что-то вроде этого:

/*
 * get this from the DAO,
 * or use the instance injected into the DAO, etc.
 */
DBCollection collection = something();
DBCursor itemsRemaining = collection.find(); //find everything
itemsRemaining.setReadPreference(ReadPreference.PRIMARY); //force query to the master
Assert.assertEquals(0, itemsRemaining.count());

Выполнение теста через DBCollection напрямую позволяет принудительно заставить тестовый запрос использовать мастер.Я бы протестировал, что findById (anyOldId) будет возвращать ноль, когда элемент не находится в коллекции в отдельном тесте.

Answer 2

На ум приходит пара мыслей

1. В производстве, если вы готовы от подчиненного, вы никогда не узнаете, получаете ли вы самые последние данные. Это компромисс чтения рабов в MongoDB. Мой опыт показывает, что в нормальных условиях труда раб работает в соответствии с современными требованиями. Если вам нужно получить самые последние данные, запросите мастер.
2. Я бы определенно начал использовать ммс для отслеживания вашей задержки реплики. Это скажет вам, как далеко позади ваших рабов, чтобы вы могли почувствовать, как быстро будут доступны данные
3. Что касается исходного вопроса тестирования, это зависит от ваших целей. Ваш DAO должен иметь возможность читать и писать одинаково, независимо от того, является ли он репликой или автономным. Вам просто нужно убедиться, что ваше приложение понимает, что данные, которые оно запрашивает, могут быть не самыми последними.