Как мне обеспечить конечную согласованность в SimpleDB, особенно в отношении модульного тестирования?

Question

Мы создаем веб-приложение на основе стека Amazon Web Services, и мне оно до сих пор нравится.

Мы также в полной мере используем разработку через тестирование, и это тоже оказывается фантастически.

Я просто надеюсь, что кто-нибудь поможет мне решить проблему, с которой я столкнулся, связанную с «конечной согласованностью» Amazon SimpleDB.

Лучшим примером возникающей проблемы является модульный тест, который добавляет пользователя, а затем проверяет, успешно ли он был добавлен, путем вызова этого вновь добавленного пользователя.

Я мог бы легко пойти дальше и просто написать тесты для этого, и все могло бы работать нормально, но я осознаю «конечную согласованность» и возможность того, что, когда я делаю вызов для извлечения пользователя, пользователь на самом деле может не быть добавил еще.Очевидно, что если вызывается функция выборки пользователя, а пользователя нет в системе, она вернет false или ошибку.

Я хотел бы знать, как лучше всего с этим справиться?Я видел предложения создать функцию, которая бездействует в течение 5 секунд между запросами и пытается выполнить 10 раз.Я также видел решения с экспоненциальным откатом.Каково оптимальное решение?

Answer 1

Я не рекомендую использовать настоящий сервис SimpleDB для модульного тестирования вашего собственного кода.Вы будете тестировать свой код + клиент SimpleDB + сеть + саму SimpleDB.Что вам нужно, так это макет клиента SimpleDB для запуска модульных тестов.Таким образом, вы тестируете только тот код, который необходимо протестировать.Разработка через тестирование призывает вас нет проверьте, работает ли база данных, в модульных тестах для вашего кода.

Если вы тестируете свой собственный клиентский код SimpleDB, вы можете использовать имитацию службы SimpleDB или что-то в этом роде. М/БД это клон SimpleDB, который можно запускать локально.

Но это порождает более серьезную проблему, поскольку SimpleDB обеспечивает конечный результат, а не согласованность чтения-записи.Ваш код обязательно должен учитывать тот факт, что вновь добавленный элемент не будет немедленно возвращен в результате получения или запроса.

У меня нет оснований думать, что ваш код не справится с этим.Я просто говорю, что, как правило, когда вы сталкиваетесь с подобными проблемами в тестах, это намекает на проблемы, которые необходимо учитывать при тестировании кода.Вы можете обнаружить, что вам нужен либо общий уровень кэширования между кодом вашего приложения и SimpleDB, либо вам может потребоваться кэш сеанса, который может обеспечить согласованность чтения-записи.

Answer 2

Так вы тестируете базу данных или код, который ей противоречит?Если вы тестируете код, который работает с базой данных, то у вас должны быть тесты, ожидающие, что код добавит пользователя, а затем не вернет пользователя, пока, скажем, не пройдет какой-то случайный промежуток времени.Очевидно, что проще всего это настроить с помощью поддельной БД, которая отслеживает количество времени с момента последнего запроса и возвращает ожидаемое значение только по истечении указанного времени с момента истечения первоначального запроса.У вас будут аналогичные тесты, в которых подделка настроена так, чтобы никогда не возвращать значение, настроена на немедленный возврат и т. д.Инструмент, который вы подделываете, чтобы отслеживать взаимодействия, и вы можете настроить в своем тесте, как вы хотите, чтобы ваш код вел себя так, чтобы ваш код следовал ожидаемому поведению (например, опрос как минимум дважды).

Answer 3

Во-первых, как заявил @Mocky, использование реальной базы данных в модульных тестах неправильно.Вы можете сделать это в интеграционных тестах, но это сработает, потому что все ваши модульные тесты пройдут успешно.

Что касается модульных тестов, которые учитывают итоговую согласованность, вот несколько идей:

1. Проверьте, что пользователь возвращается из SimpledB после его написания (без эффекта EC) Поместите пользователь получить сходство с тестированием пользователя

2. Проверьте, что пользователь не возвращается из Simpledb после его написания (EC Effect) Поместите пользователя получить ошибку

3. Проверьте, что ошибки из EC рассматриваются с получением ошибки тестирования ошибки при принятии ошибки ошибки

Я думал об использовании уровня memcache (или elasticcache) для предоставления кэшированного пользователя, поэтому, когда пользователи записываются в simpledb, они также отправляются в кеш.И когда возникают ошибки simpledb, затем проверяется кеш, прежде чем код решит, что такого пользователя действительно нет.

(на самом деле хотелось бы услышать, что вы думаете по поводу последнего абзаца)