Você pode tá estranhando o 110 sair antes do 109, mas é porque o 109 foi tão foda numa descoberta que fiz sobre como funciona o actix-web para testes que eu vou precisar de mais tempo para escrever ele.
Hoje eu defini os testes para o backend da criação de reviews no site.
Os reviews do site serão , inicialmente, todos revisados para previnir comentários maldosos 😃 e para prevenir spams, o que eu vou fazer é basicamente limitar reviews para no máximo 3 em 24h. Ai você vai dizer: “ ain, mas tem gente que esquece e vai querer fazer vários reviews ao mesmo tempo”, MENTIRA; Ninguém perde tanto tempo da vida assim (eu sei que tem, mas é minoria).
Então a ideia é prevenir um grande problema ao custo da usabilidade de alguns usuários que amem muito caldinho (não mais do que eu, eu aposto).
De toda forma, ainda não consegui resolver o problema de concorrência para acessar os recursos do banco (eu sei, eu sei, loucura), eu tive uma ideia, tentei implementar mas não funcionou muito bem no começo.
Eu lembro do conceito de Mutex mas é um saco como cada linguagem implementa de um jeito e rust não é diferente ✌🏾.
Pra quem não sabe o que é Mutex, segue link explicando bem: https://mortoray.com/cpu-memory-why-do-i-need-a-mutex/ (Leia o último parágrafo).
Depois de uns bons 30~45 minutos eu consegui resolver o problema do Mutex [https://doc.rust-lang.org/std/sync/struct.Mutex.html], basicamente eu criei um Mutex estático e deixei ele público; Assim todo código que faz parte do módulo de teste pode acessar ele.
Outro ponto importante foi fazer com que as funções que manipulam o Mutex, retornem ele? Mas porquê? (pelo menos a função que tenta coletar o Mutex).
Porque eu só preciso do Mutex em cima do container pelo tempo que o teste precisa acessar o banco, fora isto, o Mutex pode muito bem ficar livre. E se eu não retornar, a função que pega o mutex (que precisa manipular ele), vai liberar o Mutex assim que a função acabar e a variável sair do escopo. Então o jeito foi retornar o “poder” (ownership) da variável que controla o acesso ao Mutex naquele teste para a função principal do teste, assim, o lock do mutex fica na mão do teste até ele não precisar mais:
E agora que eu tenho isso no lugar, eu não preciso mais rodar os testes com uma thread só, posso rodar eles em paralelo, assim os testes unitários vão poder rodar rápido e os testes de integração (por enquanto), vão ter de rodar de forma sequencial (enquanto estiverem acessando o container de teste).
Dá pra ver que teve teste que demorou mais de 60 segundos por conta do lock, mas enfim, tá tranquilo.
O massa é que agora já tenho 21 testes e a maioria tá falhando hahaha, mas pelo menos meu código do backend vai ganhando especificações melhores com isto 😃;
Só queria deixar uma menção honrosa, um artigo que me ajudou bastante quando comecei a escrever os testes e que foi a base para todo este código utilizando mutex: https://cloudmaker.dev/actix-integration-tests/
Felipe Bormann 
Deixe um comentário