Como devo lidar com a eventual consistência no SimpleDB, principalmente em relação aos testes de unidade?

Question

Estamos construindo um aplicativo da web no topo da pilha de serviços da Web da Amazon, e estou adorando até agora.

Também estamos fazendo pleno uso do desenvolvimento orientado a testes e isso também está provando ser fantástico.

Só espero que alguém possa me ajudar com um problema que me deparei com a "eventual consistência" da Amazon Simpledb.

O melhor exemplo do problema que surge está em um teste de unidade que adiciona um usuário e verifica se o usuário foi adicionado com sucesso fazendo uma chamada para buscar esse usuário recém -adicionado.

Eu poderia facilmente seguir em frente e apenas escrever os testes para isso e tudo poderia funcionar bem, mas estou ciente da "consistência eventual" e da possibilidade de que, quando eu fizer a chamada para buscar o usuário, o usuário pode não ter sido realmente adicionado ainda. Obviamente, se a função Fetch User for chamada e o usuário não estiver no sistema, ele retornará false ou falha.

O que eu gostaria de saber é qual é a melhor maneira de lidar com isso? Vi sugestões de fazer uma função que dorme por 5 segundos entre solicitações e tentativas 10 vezes. Eu também vi soluções com retomada exponencial. Qual é a solução ideal?

Answer 1

Eu recomendo contra o uso do serviço SimpleDB real para testar seu próprio código. Você estará testando seu código + o cliente SimpleDB + a rede + simplificada. O que você precisa é o cliente simplificado da simplificação para executar testes de unidade. Dessa forma, você está testando apenas o código que precisa ser testado. O desenvolvimento orientado a testes exige que você não Teste se o banco de dados funciona nos testes de unidade para o seu código.

Se você estiver testando seu próprio código de cliente SimpleDB, poderá usar um serviço simplificado de simulação ou algo como M/dB que é um clone simplificado que você pode executar localmente.

Mas isso traz uma questão maior, porque o SimpleDB fornece consistência eventual e não leia sua consistência. Seu código precisará ser capaz de lidar com o fato de que um item recém -adicionado não será devolvido imediatamente de um GET ou de uma consulta.

Não tenho motivos para pensar que seu código não pode lidar com isso. Só estou dizendo que, como regra geral, quando você encontra problemas como esses com os testes, ela sugere questões que precisam ser consideradas com o código que está sendo testado. Você pode achar que deseja uma camada geral de armazenamento em cache entre o código do seu aplicativo e o SimpleDB ou pode querer um cache de sessão que possa fornecer consistência de leitura de seus escritores.

Answer 2

Então você está testando o banco de dados ou o código que vai contra ele? Se você estiver testando o código que vai contra o banco de dados, deve ter testes que esperam que o código adicione um usuário e não retorne um usuário até que, por exemplo, algum tempo aleatório tenha passado. Obviamente, isso é mais facilmente configurado usando um banco de dados falso que acompanha a quantidade de tempo desde a última solicitação e retorna apenas o valor esperado após o tempo especificado, pois a solicitação inicial decorrida. Você teria testes semelhantes em que o falso é configurado para nunca retornar o valor, configurado para devolvê -lo imediatamente, etc. Instrumento que você finge para acompanhar as interações e pode configurar em seu teste como deseja que seu código Para se comportar, para que seu código siga o comportamento esperado (pesquisando pelo menos duas vezes, por exemplo).

Answer 3

Primeiro, como o @Mocky afirmou, atingir o banco de dados real em testes de unidade está errado. Você pode fazer isso nos testes de integração, mas isso funcionaria porque todos os seus testes de unidade passam.

Em relação aos testes de unidade que estão cientes da consistência eventual, aqui estão algumas idéias:

1. Teste que o usuário é devolvido do SimpleDB após o seu escrito (sem efeito da CE), coloque o usuário, obtenha o teste do usuário Smenessness

2. Teste que o usuário não é devolvido do SimpleDB após o seu (efeito CE), coloque o usuário, que o usuário aceite um erro

3. teste que os erros da CE são tratados com o usuário do usuário + aceitar o erro de teste é tratado

Eu estava pensando em usar uma camada de memcache (ou elasticcache) para fornecer um usuário em cache; portanto, quando os usuários são gravados para simplificar, eles também são enviados para o cache. E quando os erros simplificados ocorrem, o cache é verificado a seguir antes que o código decida que realmente não existe esse usuário.

(Na verdade, adoraria ouvir o que você pensa sobre esse último parágrafo)