Blog Eduardo Klosowski

Branch para deploy de validação

2025-09-25T00:00:00+00:00

Em um projeto de software é comum precisar testar uma funcionalidade que está sendo ou foi desenvolvida. Nos projetos em que o código roda em um servidor, isso pode envolver o deploy em algum ambiente específico, permitindo assim testar uma versão específica do código interagindo com as aplicações cliente ou demais serviços. Porém quando mais de uma funcionalidade é desenvolvida ao mesmo tempo em branches diferentes do git, muitas vezes por pessoas diferentes, testar duas ou mais funcionalidades ao mesmo tempo pode não ser trivial.</p>

Exemplificando o problema</h2>

Um fluxo bastante comum usado no git é criar uma branch para desenvolver uma funcionalidade. Quando essa funcionalidade estiver pronta, e preferencialmente testada, é feito o merge para a branch principal do projeto. Isso permite que diferentes funcionalidades sejam desenvolvidas em paralelo, seguindo cada uma as etapas do seu fluxo de trabalho, sem ou com a menor interferência possível, assim como também permite desistir do desenvolvimento de uma funcionalidade ou recomeçá-lo.</p>

Um exemplo de diferentes branches do git pode ser visto a baixo:</p>

    gitGraph
    commit id: "0"
    branch feature-1
    commit id: "1"
    commit id: "2"
    checkout main
    branch feature-2
    commit id: "3"
    commit id: "4"
</pre>
Se considerar que o projeto é o código de uma API Rest que é executado em um servidor, e que existem alguns ambientes diferentes como:</p>

Produção</code>: ambiente em que o projeto está de fato sendo utilizado. Deploy realizado a partir da branch main</code>.</li>
Homologação</code>: ambiente para validação antes de ir para produção. Deploy realizado a partir da branch main</code>.</li>
Desenvolvimento</code>: ambiente para testar as coisas pelos desenvolvedores, sem necessariamente se comprometer em levar para produção o que é feito aqui. Deploy realizado a partir de qualquer branch.</li>
</ul>
Caso as pessoas que desenvolveram as branches feature-1</code> e feature-2</code> queiram testar seus códigos no ambiente Desenvolvimento</code>, apenas uma versão (branch) poderá ser testada por vez, já que ao realizar o deploy da versão do commit 4</code>, ele substituirá o deploy da versão do commit 2</code>, por exemplo, e vice-versa.</p>
Proposta de solução</h2>
Uma forma de abordar esse problema é através da criação uma versão com todas as funcionalidades que se deseja testar. No git isso pode ser feito criando outra branch para reunir as branches desejadas (fazer merge delas). Por exemplo, executando os seguintes comandos:</p>
git</span> checkout</span> -b</span> desenvolvimento main</span></span>
git</span> merge</span> --no-ff</span> feature-1</span></span>
git</span> merge</span> --no-ff</span> feature-2</span></span></code></pre>
O que geraria o seguinte histórico no git:</p>
    gitGraph
    commit id: "0"
    branch feature-1 order: 2
    commit id: "1"
    commit id: "2"
    checkout main
    branch feature-2 order: 3
    commit id: "3"
    commit id: "4"
    checkout main
    branch desenvolvimento order: 1
    merge feature-1 id: "5"
    merge feature-2 id: "6"
</pre>
Assim ao realizar o deploy no ambiente Desenvolvimento</code> sempre a partir da branch desenvolvimento</code>, isso permite testar todas as funcionalidades desejadas ao mesmo tempo, nesse caso as funcionalidades presentes nas branches feature-1</code> e feature-2</code>. Porém essas funcionalidades ainda terão suas respectivas branches separadas para continuar seu fluxo de trabalho, como abertura de pull request (PR) ou merge request (MR), revisão de código e demais etapas que podem existir sem se misturar com as outras, não se importando com a branch desenvolvimento</code>.</p>
A branch desenvolvimento</code> ainda poderá receber novas funcionalidades de outras branches, alterações das branches que já havia feito o merge anteriormente. Ou seja, novas versões podem ser feitas nessa branch conforme a necessidade. Um exemplo é um teste de alteração na feature-1</code> (commit 7</code>), que foi feito o merge e deploy (versão no commit 8</code>), e se não teve o resultado esperado, poderá ser revertido:</p>
    gitGraph
    commit id: "0"
    branch feature-1 order: 2
    commit id: "1"
    commit id: "2"
    checkout main
    branch feature-2 order: 3
    commit id: "3"
    commit id: "4"
    checkout main
    branch desenvolvimento order: 1
    merge feature-1 id: "5"
    merge feature-2 id: "6"
    checkout feature-1
    commit id: "7"
    checkout desenvolvimento
    merge feature-1 id: "8"
    commit id: "REVERTE-8" type: REVERSE
</pre>
Entrega das funcionalidades</h3>
Quando uma funcionalidade for validada e estiver dada como pronta, poderá seguir seu fluxo de trabalho normal, sendo feito o merge de sua branch com a main</code>, como se a branch desenvolvimento</code> não existisse. Desta forma apenas essa funcionalidade integrará a branch main</code>, podendo ser validada no ambiente Homologação</code> e chegar a Produção</code>, sem as demais funcionalidades que ainda estão sendo testadas no ambiente Desenvolvimento</code>. E ela pode se juntar a outras funcionalidades, como uma pequena correção que foi aplicada diretamente na branch main</code>(ambientes Homologação</code> e Produção</code>), sem ter passado pela branch desenvolvimento</code>.</p>
    gitGraph
    commit id: "0"
    branch feature-1 order: 2
    commit id: "1"
    commit id: "2"
    checkout main
    branch feature-2 order: 3
    commit id: "3"
    commit id: "4"
    checkout main
    branch desenvolvimento order: 1
    merge feature-1 id: "5"
    merge feature-2 id: "6"
    checkout feature-1
    commit id: "7"
    checkout desenvolvimento
    merge feature-1 id: "8"
    commit id: "REVERTE-8" type: REVERSE
    checkout feature-1
    commit id: "REVERTE-7" type: REVERSE
    checkout main
    branch fix-3 order: 4
    commit id: "9"
    checkout main
    merge fix-3 id: "10"
    merge feature-2 id: "11"
</pre>
Limpeza da branch</h3>
A funcionalidade foi testada na branch desenvolvimento</code> e entregue na branch main</code>, porém é possível observar que com o passar do tempo pode a surgir diferenças entre o código das branches desenvolvimento</code> e main</code>. Um caso foi a correção fix-3</code>, que foi aplicada diretamente na main</code>, sem passar pela desenvolvimento</code>, e outro caso poderia ser a feature-1</code>, se seu desenvolvimento for pausado ou cancelado. Isso é ruim, pois poderia gerar código que funciona na desenvolvimento</code>, mas não na main</code>.</p>
Desta forma é recomendável fazer limpeza da branch desenvolvimento</code>, que seria uma ressincronização com a branch main</code> da onde ela surgiu. Ao fazer isso, serão removidas dela todas as funcionalidades que não chegaram na branch main</code>, porém como essas funcionalidades ainda terão suas branches individuais, seus merges podem ser refeitos com a branch desenvolvimento</code> se ainda for relevante e seu teste estiver ocorrendo. E se não, essa funcionalidade deixará de influenciar nos testes das demais.</p>
Essa limpeza pode ser efetuada simplesmente recriando a branch, por exemplo:</p>
git</span> checkout</span> -B</span> desenvolvimento main</span></span></code></pre>
E ao unir a feature-1</code> para testes na desenvolvimento</code>, o histórico seria o seguinte:</p>
    gitGraph
    commit id: "0"
    branch feature-1 order: 2
    commit id: "1"
    commit id: "2"
    checkout main
    branch feature-2 order: 3
    commit id: "3"
    commit id: "4"
    checkout feature-1
    commit id: "7"
    commit id: "REVERTE-7" type: REVERSE
    checkout main
    branch fix-3 order: 4
    commit id: "9"
    checkout main
    merge feature-2 id: "10"
    merge fix-3 id: "11"
    branch desenvolvimento order: 1
    merge feature-1 id: "13"
</pre>
Embora essa limpeza seja boa para manter as branches desenvolvimento</code> e main</code> semelhantes, evitando assim alguns problemas, uma frequência muito grande também pode dificultar os testes, uma vez que desativará as funcionalidades que estão em teste. Desta forma é necessário encontrar um equilíbrio, seja uma vez por dia ou semana, e isso pode mudar conforme o projeto. Outra opção é a criação de um "botão de manual", que poderia ser usado sempre que se achar necessário, e que pode até trabalhar em conjunto com algum agendamento.</p>
Como implementar?</h2>
Os comandos sugeridos anteriormente funcionam no repositório local. Para integrar com um repositório remoto é necessário algumas adaptações.</p>
Criando ou limpando a branch</h3>
Para criar ou limpar a branch desenvolvimento</code> é necessário ter a branch main</code> atualizada, criar a branch desenvolvimento</code> e enviar para o servidor sobreescrevendo a atual. Isso pode ser feito com a seguinte sequência de comandos:</p>
git</span> fetch origin main</span></span>
git</span> checkout</span> -B</span> desenvolvimento origin/main</span></span>
git</span> push origin +desenvolvimento</span></span></code></pre>Merge de funcionalides para teste</h3>
Para adicionar uma funcionalidade na branch desenvolvimento</code> é necessário ter as branches desenvolvimento</code> e da funcionalidade desejada atualizada, após isso é necessário fazer o merge e enviar para o servidor. Isso pode ser feito com a seguinte sequência de comandos:</p>
git</span> fetch origin desenvolvimento feature-1</span></span>
git</span> checkout</span> -B</span> desenvolvimento origin/desenvolvimento</span></span>
git</span> merge</span> --no-ff</span> origin/feature-1</span></span>
git</span> push origin desenvolvimento</span></span></code></pre>
Caso alterações sejam feitas na branch da funcionalidade depois disso, é possível fazer um novo merge.</p>
Revertendo alterações</h3>
Caso alguma funcionalidade apresente erro, ou se deseja removê-la sem mexer nas demais, é possível reverter um merge na desenvolvimento</code>. A forma para ter isso é ter a branch desenvolvimento</code> atualiza e usar o próprio git para gerar um commit desfazendo as alterações do merge. Isso pode ser feito com a seguinte sequência de comandos informando o hash do commit de merge:</p>
git</span> fetch origin desenvolvimento</span></span>
git</span> checkout</span> -B</span> desenvolvimento origin/desenvolvimento</span></span>
git</span> revert</span> -m 1</span> aa9ff52</span></span></code></pre>
Um ponto a se observar é que ao fazer um commit revertendo as alterações de um merge, não será mais possível fazer o merge dessa funcionalidade até a branch desenvolvimento</code> ser limpa, uma vez que os commits da branch dessa funcionalidade já estão no histórico da desenvolvimento</code>. Porém é possível reverter um commit que reverteu o merge, trazendo a funcionalidade de volta.</p>
Onde executar?</h3>
Uma forma de executar essas sequências de comandos é através de um script, onde quem desejar poderia executá-lo e passar qual a operação desejada, branch e afins.</p>
Outra opção é utilizar alguma ferramenta de integração contínua (CI), assim bastaria executar um job passando as mesmas informações como parâmetro. Caso não tenha alguma ferramenta de CI e o deploy da aplicação for feito no Kubernetes</a>, é possível utilizar o Tekton</a> para isso, ele irá executar o job usando o próprio Kubernetes para isso.</p>
Considerações</h2>
Não existe uma forma trivial de testar diferentes branches juntas, porém é possível fazer um fluxo com uma branch a parte para isso, sendo que essa branch não vai interferir no fluxo de trabalho anterior, ficando apenas como um passo opcional. Porém é necessário implementar algumas funcionalidades com sequências de comandos para isso.</p>
O fluxo apresentado visa fazer um único deploy com todas as funcionalidades desejadas. Outra opção seria fazer um deploy separado para cada branch, dando um endereço diferente para acessá-los. Essa outra forma permitiria testar as funcionalidades de forma isolada, porém cada deploy consumiria recursos e poderia ter dificuldades caso seja necessário integrar esse novo deploy em algum serviço, como receber eventos ou mensagens de outros serviços.</p>



Testando código que chama serviços da AWS
2025-02-04T00:00:00+00:00
Eu desenvolvo sistemas que utilizam os serviços da AWS</a> faz algum tempo, e ao longo desse tempo houve mudanças na forma como escrevo testes de código que fazem chamadas a seus serviços. Esse texto tem como objetivo apresentar algumas abordagens para escrita de testes que utilizei, e discutir o que motivou suas evoluções, destacando características de cada abordagem. Ao final, pretendo apresentar um padrão que acredito ser uma forma bastante prática de escrever testes de código que interage com serviços da AWS, usando uma biblioteca em Python</a> que desenvolvi implementando esse padrão, mas que também poderia ser adaptado para outros contextos (serviços) e linguagens.</p>
Código a ser testado</h2>
Antes de iniciar a discussão sobre os testes, quero apresentar um exemplo de código para ser testado. Ele é uma função que deve consumir mensagens enviadas para uma fila SQS</a>, realizar um processamento com a informação contida nas mensagens, e enviar o resultado para outra fila SQS.</p>
import</span> json</span></span>
</span>
def</span> funcao1</span>(</span>cliente_sqs</span>,</span> fila1_url</span>,</span> fila2_url</span>):</span></span>
    # Recebe até 10 mensagens do SQS</span></span>
    msgs_recebidas</span> =</span> cliente_sqs.</span>receive_message</span>(</span></span>
        QueueUrl</span>=</span>fila1_url,</span></span>
        MaxNumberOfMessages</span>=</span>10</span>,</span></span>
    )</span></span>
</span>
    # Percorre as mensagens recebidas</span></span>
    for</span> msg</span> in</span> msgs_recebidas.</span>get</span>(</span>'Messages'</span>, []):</span></span>
        # Recupera valor da mensagem</span></span>
        corpo</span> =</span> json.</span>loads</span>(msg[</span>'Body'</span>])</span></span>
        n</span> =</span> corpo[</span>'n'</span>]</span></span>
</span>
        # Processa valor</span></span>
        resultado</span> =</span> n</span> *</span> 2</span></span>
        resposta</span> =</span> {</span>'resultado'</span>: resultado}</span></span>
</span>
        # Envia mensagem com resultado</span></span>
        cliente_sqs.</span>send_message</span>(</span></span>
            QueueUrl</span>=</span>fila2_url,</span></span>
            MessageBody</span>=</span>json.</span>dumps</span>(resposta),</span></span>
        )</span></span>
</span>
        # Apaga mensagem atual</span></span>
        cliente_sqs.</span>delete_message</span>(</span></span>
            QueueUrl</span>=</span>fila1_url,</span></span>
            ReceiptHandle</span>=</span>msg[</span>'ReceiptHandle'</span>],</span></span>
        )</span></span></code></pre>
Esse código é uma função que recebe um objeto para interagir com o serviço SQS (cliente_sqs</code>) e a URL de duas filas (fila1_url</code> e fila2_url</code>). Ele busca até 10 mensagens da fila1_url</code> (o máximo permitido por chamada), cada mensagem é um JSON</a> que possui um número no campo n</code>. Após recuperar esse valor, um processamento é feito (nesse caso multiplicar o valor por 2</code>), um novo JSON é gerado e enviado para a fila2_url</code>. Se tudo isso ocorrer conforme esperado, a mensagem processada é removida da fila1_url</code>, evitando que ela volte para a fila e eventualmente ser feito uma nova tentativa de processá-la. Esse processo é repetido para cada mensagem recebida.</p>
Teste unitário com mock</em></h2>
Uma forma bastante simples de testar é fazer testes unitários (também chamados de testes de unidade</a>) e usar mocks</em></a>. Para o código de exemplo é possível criar um objeto que simula (mock</em>) o cliente_sqs</code> passado para a função, e registre as funções chamadas dele. Depois de executar a função a ser testada, basta verificar as chamadas feitas no objeto simulado, e assim validar se a função está se comportando como o esperado.</p>
Na biblioteca padrão do Python existe o MagicMock</code></a>, que facilita a criação de mocks</em>. Bastando definir o que deve ser retornando em cada função (se ela tiver retorno), e depois verificar como suas funções foram chamadas (assert</code>). Caso espera-se que uma função tenha sido chamada de determinada forma e isso não ocorreu, o teste falhará.</p>
Segue a baixo um exemplo de teste unitário com mock</em> para o código apresentado anteriormente:</p>
import</span> json</span></span>
from</span> exemplo.codigo1</span> import</span> funcao1</span></span>
from</span> unittest.mock</span> import</span> MagicMock</span></span>
from</span> uuid</span> import</span> uuid4</span></span>
</span>
def</span> test_funcao1</span>():</span></span>
    # Mensagens com valores de entrada e resultados esperados</span></span>
    msgs</span> =</span> [</span></span>
        {</span>'n'</span>:</span> 0</span>},</span></span>
        {</span>'n'</span>:</span> 1</span>},</span></span>
        {</span>'n'</span>:</span> 2</span>},</span></span>
    ]</span></span>
    respostas</span> =</span> [</span></span>
        {</span>'resultado'</span>:</span> 0</span>},</span></span>
        {</span>'resultado'</span>:</span> 2</span>},</span></span>
        {</span>'resultado'</span>:</span> 4</span>},</span></span>
    ]</span></span>
</span>
    # Define outros valores auxiliares para o teste</span></span>
    fila1_url</span> =</span> 'http://sqs.aws/fila1'</span></span>
    fila2_url</span> =</span> 'http://sqs.aws/fila2'</span></span>
    msgs_mockadas</span> =</span> [</span></span>
        {</span></span>
            'ReceiptHandle'</span>:</span> uuid4</span>().hex,</span></span>
            'Body'</span>: json.</span>dumps</span>(msg),</span></span>
        }</span> for</span> msg</span> in</span> msgs</span></span>
    ]</span></span>
</span>
    # Cria e configura mock do SQS</span></span>
    mock_cliente_sqs</span> =</span> MagicMock</span>()</span></span>
    mock_cliente_sqs.receive_message.return_value</span> =</span> {</span></span>
        'Messages'</span>: msgs_mockadas,</span></span>
    }</span></span>
</span>
    # Chama função a ser testada</span></span>
    funcao1</span>(mock_cliente_sqs, fila1_url, fila2_url)</span></span>
</span>
    # Verifica se a função buscou as mensagens na fila 1</span></span>
    mock_cliente_sqs.receive_message.</span>assert_called_once_with</span>(</span></span>
        QueueUrl</span>=</span>fila1_url,</span></span>
        MaxNumberOfMessages</span>=</span>10</span>,</span></span>
    )</span></span>
</span>
    # Verifica se as mensagens da fila 1 foram apagadas</span></span>
    assert</span> mock_cliente_sqs.delete_message.call_count</span> == len</span>(msgs)</span></span>
    for</span> msg</span> in</span> msgs_mockadas:</span></span>
        mock_cliente_sqs.delete_message.</span>assert_any_call</span>(</span></span>
            QueueUrl</span>=</span>fila1_url,</span></span>
            ReceiptHandle</span>=</span>msg[</span>'ReceiptHandle'</span>],</span></span>
        )</span></span>
</span>
    # Verifica se as respostas estão corretas na fila 2</span></span>
    assert</span> mock_cliente_sqs.send_message.call_count</span> == len</span>(respostas)</span></span>
    for</span> esperado</span> in</span> respostas:</span></span>
        mock_cliente_sqs.send_message.</span>assert_any_call</span>(</span></span>
            QueueUrl</span>=</span>fila2_url,</span></span>
            MessageBody</span>=</span>json.</span>dumps</span>(esperado),</span></span>
        )</span></span></code></pre>
Essa abordagem tem algumas vantagens, como: Não precisar configurar e acessar o serviço SQS para rodar os testes, executando tudo localmente; E testa um trecho de código de forma isolada (uma função nesse caso), independente de outras partes do código, como o cliente_sqs</code>. Porém esse método também apresenta desvantagens, como: Ao isolar uma parte do código, perde-se a certeza se ele funcionará junto com as demais partes do sistema, uma vez que podem existir diferenças entre uma resposta real e a resposta do mock</em> (nesse teste o msgs_mockadas</code> possui apenas duas chaves, quando numa resposta verdadeira existiriam várias outras também); Além de ser necessário definir toda vez qual o retorno das funções e validar se elas foram chamadas conforme o esperado; Também é possível fazer um mock</em> que aceite uma chamada inválida para o serviço real; E como a mensagem enviada é uma string com JSON, a ordem dos campos pode mudar, assim como sua formatação, o que pode causar un falso negativo no teste. Então qualquer alteração de parâmetros da função ou resposta, pode gerar uma incompatibilidade do mock</em> com o comportamento real do sistema.</p>
Teste de integração com uma reimplementação</h2>
Partindo mais para uma abordagem de testes de integração, existe uma reimplementação dos serviços da AWS em Python para ser usada em testes chamada Moto</a> (que também pode ser utilizada em outras linguagens no seu modo servidor</a>, semelhante ao LocalStack</a>). Assim também é possível rodar os testes localmente, uma vez que ele simula o comportamento dos serviços da AWS. Um exemplo de teste utilizando essa biblioteca pode ser visto a baixo:</p>
import</span> boto3</span></span>
import</span> json</span></span>
from</span> exemplo.codigo1</span> import</span> funcao1</span></span>
from</span> moto</span> import</span> mock_aws</span></span>
</span>
@mock_aws</span></span>
def</span> test_funcao1</span>():</span></span>
    # Mensagens com valores de entrada e resultados esperados</span></span>
    msgs</span> =</span> [</span></span>
        {</span>'n'</span>:</span> 0</span>},</span></span>
        {</span>'n'</span>:</span> 1</span>},</span></span>
        {</span>'n'</span>:</span> 2</span>},</span></span>
    ]</span></span>
    respostas</span> =</span> [</span></span>
        {</span>'resultado'</span>:</span> 0</span>},</span></span>
        {</span>'resultado'</span>:</span> 2</span>},</span></span>
        {</span>'resultado'</span>:</span> 4</span>},</span></span>
    ]</span></span>
</span>
    # Conecta no SQS</span></span>
    cliente_sqs</span> =</span> boto3.</span>client</span>(</span>'sqs'</span>,</span> region_name</span>=</span>'us-east-1'</span>)</span></span>
</span>
    # Cria filas de teste</span></span>
    fila1_url</span> =</span> cliente_sqs.</span>create_queue</span>(</span>QueueName</span>=</span>'fila1'</span>)[</span>'QueueUrl'</span>]</span></span>
    fila2_url</span> =</span> cliente_sqs.</span>create_queue</span>(</span>QueueName</span>=</span>'fila2'</span>)[</span>'QueueUrl'</span>]</span></span>
</span>
    # Envia mensagens de teste</span></span>
    for</span> msg</span> in</span> msgs:</span></span>
        cliente_sqs.</span>send_message</span>(</span></span>
            QueueUrl</span>=</span>fila1_url,</span></span>
            MessageBody</span>=</span>json.</span>dumps</span>(msg),</span></span>
        )</span></span>
</span>
    # Chama função a ser testada</span></span>
    funcao1</span>(cliente_sqs, fila1_url, fila2_url)</span></span>
</span>
    # Verifica se a função buscou e apagou as mensagens na fila 1</span></span>
    assert</span> sum</span>(</span>int</span>(attr)</span> for</span> attr</span> in</span> cliente_sqs.</span>get_queue_attributes</span>(</span></span>
        QueueUrl</span>=</span>fila1_url,</span></span>
        AttributeNames</span>=</span>[</span></span>
            'ApproximateNumberOfMessages'</span>,</span></span>
            'ApproximateNumberOfMessagesNotVisible'</span>,</span></span>
        ],</span></span>
    )[</span>'Attributes'</span>].</span>values</span>())</span> ==</span> 0</span></span>
</span>
    # Verifica se as respostas estão corretas na fila 2</span></span>
    msgs_de_resposta</span> =</span> cliente_sqs.</span>receive_message</span>(</span></span>
        QueueUrl</span>=</span>fila2_url,</span></span>
        MaxNumberOfMessages</span>=</span>10</span>,</span></span>
    )[</span>'Messages'</span>]</span></span>
    for</span> msg</span> in</span> msgs_de_resposta:</span></span>
        cliente_sqs.</span>delete_message</span>(</span></span>
            QueueUrl</span>=</span>fila2_url,</span></span>
            ReceiptHandle</span>=</span>msg[</span>'ReceiptHandle'</span>],</span></span>
        )</span></span>
    assert</span> [</span></span>
        json.</span>loads</span>(msg[</span>'Body'</span>])</span> for</span> msg</span> in</span> msgs_de_resposta</span></span>
    ]</span> ==</span> respostas</span></span>
</span>
    # Remove filas de teste</span></span>
    cliente_sqs.</span>delete_queue</span>(</span>QueueUrl</span>=</span>fila1_url)</span></span>
    cliente_sqs.</span>delete_queue</span>(</span>QueueUrl</span>=</span>fila2_url)</span></span></code></pre>
Diferente do teste anterior, neste não é necessário se preocupar em montar os retornos dos serviços acessados, porém é necessário conhecer melhor o serviço para criar os recursos utilizados pela função a ser testada. Também não existe uma forma de fazer um assert</code> para verificar se uma mensagem foi enviada, é necessário buscá-las da fila, e nesse caso, também chamar a função para removê-las, de forma que elas não voltem para a fila, evitando comportamentos não esperados (embora não seja obrigatório ao usar o Moto como um decorador, mas é bom para evitar problemas). E mesmo que possa existir alguma diferença entre o serviço real e sua reimplementação, espera-se que ele seja confiável, e ao atualizar o Moto, todos os testes já serão validados com os novos comportamentos, terceirizando essa responsabilidade do teste.</p>
Interagindo com outro serviço (SNS)</h2>
Pensando em testar outro serviço da AWS, pode-se trocar a fila SQS para qual a resposta do código é enviada por um tópico SNS</a>. O código a ser testado então fica:</p>
import</span> json</span></span>
</span>
def</span> funcao2</span>(</span>cliente_sqs</span>,</span> cliente_sns</span>,</span> fila_url</span>,</span> topico_arn</span>):</span></span>
    # Recebe até 10 mensagens do SQS</span></span>
    msgs_recebidas</span> =</span> cliente_sqs.</span>receive_message</span>(</span></span>
        QueueUrl</span>=</span>fila_url,</span></span>
        MaxNumberOfMessages</span>=</span>10</span>,</span></span>
    )</span></span>
</span>
    # Percorre as mensagens recebidas</span></span>
    for</span> msg</span> in</span> msgs_recebidas.</span>get</span>(</span>'Messages'</span>, []):</span></span>
        # Recupera valor da mensagem</span></span>
        corpo</span> =</span> json.</span>loads</span>(msg[</span>'Body'</span>])</span></span>
        n</span> =</span> corpo[</span>'n'</span>]</span></span>
</span>
        # Processa valor</span></span>
        resultado</span> =</span> n</span> *</span> 2</span></span>
        resposta</span> =</span> {</span>'resultado'</span>: resultado}</span></span>
</span>
        # Publica mensagem com resultado</span></span>
        cliente_sns.</span>publish</span>(</span></span>
            TopicArn</span>=</span>topico_arn,</span></span>
            Message</span>=</span>json.</span>dumps</span>(resposta),</span></span>
        )</span></span>
</span>
        # Apaga mensagem atual</span></span>
        cliente_sqs.</span>delete_message</span>(</span></span>
            QueueUrl</span>=</span>fila_url,</span></span>
            ReceiptHandle</span>=</span>msg[</span>'ReceiptHandle'</span>],</span></span>
        )</span></span></code></pre>
Seu teste pode seguir uma estrutura bastante similar:</p>
import</span> boto3</span></span>
import</span> json</span></span>
from</span> exemplo.codigo2</span> import</span> funcao2</span></span>
from</span> moto</span> import</span> mock_aws</span></span>
</span>
@mock_aws</span></span>
def</span> test_funcao2</span>():</span></span>
    # Mensagens com valores de entrada e resultados esperados</span></span>
    msgs</span> =</span> [</span></span>
        {</span>'n'</span>:</span> 0</span>},</span></span>
        {</span>'n'</span>:</span> 1</span>},</span></span>
        {</span>'n'</span>:</span> 2</span>},</span></span>
    ]</span></span>
    respostas</span> =</span> [</span></span>
        {</span>'result'</span>:</span> 0</span>},</span></span>
        {</span>'result'</span>:</span> 2</span>},</span></span>
        {</span>'result'</span>:</span> 4</span>},</span></span>
    ]</span></span>
</span>
    # Conecta no SQS e SNS</span></span>
    cliente_sqs</span> =</span> boto3.</span>client</span>(</span>'sqs'</span>,</span> region_name</span>=</span>'us-east-1'</span>)</span></span>
    cliente_sns</span> =</span> boto3.</span>client</span>(</span>'sns'</span>,</span> region_name</span>=</span>'us-east-1'</span>)</span></span>
</span>
    # Cria fila e tópico de teste</span></span>
    fila_url</span> =</span> cliente_sqs.</span>create_queue</span>(</span>QueueName</span>=</span>'fila'</span>)[</span>'QueueUrl'</span>]</span></span>
    topico_arn</span> =</span> cliente_sns.</span>create_topic</span>(</span>Name</span>=</span>'topico'</span>)[</span>'TopicArn'</span>]</span></span>
</span>
    # Envia mensagens de teste</span></span>
    for</span> msg</span> in</span> msgs:</span></span>
        cliente_sqs.</span>send_message</span>(</span></span>
            QueueUrl</span>=</span>fila_url,</span></span>
            MessageBody</span>=</span>json.</span>dumps</span>(msg),</span></span>
        )</span></span>
</span>
    # Chama função a ser testada</span></span>
    funcao2</span>(cliente_sqs, cliente_sns, fila_url, topico_arn)</span></span>
</span>
    # Como fazer um assert das mensagens publicadas no SNS?</span></span>
    assert</span> ...</span></span>
</span>
    # Remove fila e tópico de teste</span></span>
    cliente_sqs.</span>delete_queue</span>(</span>QueueUrl</span>=</span>fila_url)</span></span>
    cliente_sns.</span>delete_topic</span>(</span>TopicArn</span>=</span>topico_arn)</span></span></code></pre>
Porém como verificar o que foi enviado para o tópico SNS? Como mocks</em> não estão sendo utilizados, não tem como fazer um assert</code> para verificar se a função foi chamada e com quais parâmetros. O SNS também não tem uma forma direta de recuperar as mensagens publicadas nele. Uma solução possível é criar uma fila SQS, assinar o tópico SNS, de forma que tudo que for enviado para o tópico seja encaminhado para a fila SQS, e validar o tópico SNS a partir da fila SQS (e após a execução do teste, remover a assinatura, fila e tópico). Embora possível, essa solução é bastante trabalhosa e repetitiva, ainda mais se considerar que isso precisará ser refeito em cada teste do projeto que chamar o SNS.</p>
Simplificando e padronizando (repensando os testes)</h2>
Embora a solução apresentada tenha o problema da repetição de código, ela funciona, e para os testes não importa saber criar uma fila ou tópico e removê-los depois (que é uma parte considerável do que é repetido), só importa usá-los. É totalmente plausível (pelo menos na ideia), de na hora de rodar o teste, só perguntar por alguma fila disponível que possa ser utilizada, e depois devolvê-la. Então seria bom se tivesse uma forma de pegar filas e tópicos emprestados para os testes, ou até mesmo criá-los e removê-los, o teste em si não precisa saber o que acontecerá com esses recursos depois de utilizá-los. Na verdade, o teste nem precisaria saber do detalhe de que é necessário primeiro buscar uma mensagem da fila do SQS, e depois deletar essa mensagem, nem de que a mensagem publicada em um tópico SNS precisou passar por uma fila SQS para ser validada.</p>
Pensando dessa forma, só é necessário executar algum código antes do teste para criar os recursos (filas, tópicos...) que serão utilizados, e executar algum código depois dos testes para remover esses recursos criados anteriormente. Além disso, alguma abstração poderia ser criada para simplificar a interação com esses recursos na parte dos testes para facilitar a verificação de sua utilização, que é justamente a parte que importa dos testes.</p>
Para executar algum código antes e depois de algo, no Python pode-se ser usado um contexto gerenciado</a> (aquele criado com a estrutura with ...</code>), que poderia criar os recursos, passá-lo para o teste, e assim que ele acabar, fazer sua remoção. Porém, o que ele deveria retornar?</p>
Para testar um código que envia mensagens para uma fila SQS, só é necessário saber qual a fila e alguma forma de receber as mensagens enviadas. A identificação de uma fila no SQS se dá através de uma URL, e um gerador</a> poderia ser criado para abstrair toda a lógica de consumir a fila. Já para testar um código que recebe mensagens de uma fila SQS é necessário saber a URL da fila, e uma função para enviar as mensagens que serão consumidas pelo código a ser testado.</p>
Agora considerando o caso do tópico SNS, toda vez que um tópico for criado, também poderia se criar uma fila SQS que assina esse tópico. A função geradora também poderia buscar nessa fila as mensagens. Isso deixaria o SQS totalmente transparente para os testes (o teste nem saberia que tem uma fila SQS sendo utilizada). Porém para fazer a assinatura, a URL da fila não serve, é necessário seu ARN</a>, em outros contextos pode ser necessário o nome e não URL ou ARN.</p>
Para o contexto retornar mais de uma coisa, pode-se utilizar as tuplas</a> do Python. Porém a questão continua, o que estará nessa tupla? URL da fila? ARN da fila? Nome? Função para enviar mensagens? Gerador para consumir mensagens? Para não ser necessário criar diferentes tuplas para cada caso, pode-se criar uma tupla retornando tudo. Mas pode ser complicado lembrar em que posição está cada coisa, e um código que recebe uma tupla com vários valores e não utiliza a maioria pode gerar confusão. Então em vez de usar tuplas, pode-se criar um objeto seguindo o modelo de dados do Python</a>, assim informações (como nome, ARN e URL) podem ir como atributos, a função para enviar mensagens poderia ser um método, e esse objeto também poderia se comportar como um iterador, que é um comportamento do gerador. E por seguir o modelo de dados do Python, isso tudo ainda pareceria algo nativo do Python, onde um objeto abstrairia a fila SQS ou tópico SNS (algo semelhante ao page object</em></a> apresentado no curso de Selenium do Dunossauro</a>).</p>
E para facilitar ainda mais, esses contextos que criam os recursos podem se tornar fixtures</em></a> do pytest</a>, assim bastaria informar o nome da fixture</em> como parâmetro da função de teste que o recurso já seria criado, e assim que o teste terminar, removido.</p>
Implementando esses padrões nos testes</h2>
Os padrões apresentados foram implementados numa biblioteca chamada pytest-moto-fixtures</a> (também publicada no PyPI</a>), assim é possível reutilizá-lo em diferentes testes. Para códigos que utilizam SQS, segue a implementação do objeto da fila SQS</a>, contexto para criar fila SQS</a> e fixture</em> da fila SQS</a> no repositório. Da mesma forma, para códigos que utilizam SNS, segue a implementação do objeto do tópico SNS</a>, contexto para criar tópico SNS</a> e fixture</em> do tópico SNS</a>.</p>
Após instalar a biblioteca, o teste da função que recebe mensagens de uma fila SQS e publica a resposta em um tópico SNS fica da seguinte forma:</p>
import</span> json</span></span>
from</span> exemplo.codigo2</span> import</span> funcao2</span></span>
</span>
def</span> test_funcao2</span>(</span>sqs_queue</span>,</span> sns_topic</span>):</span></span>
    # Mensagens com valores de entrada e resultados esperados</span></span>
    msgs</span> =</span> [</span></span>
        {</span>'n'</span>:</span> 0</span>},</span></span>
        {</span>'n'</span>:</span> 1</span>},</span></span>
        {</span>'n'</span>:</span> 2</span>},</span></span>
    ]</span></span>
    respostas</span> =</span> [</span></span>
        {</span>'resultado'</span>:</span> 0</span>},</span></span>
        {</span>'resultado'</span>:</span> 2</span>},</span></span>
        {</span>'resultado'</span>:</span> 4</span>},</span></span>
    ]</span></span>
</span>
    # Envia mensagens de teste</span></span>
    for</span> msg</span> in</span> msgs:</span></span>
        sqs_queue.</span>send_message</span>(</span>body</span>=</span>msg)</span></span>
</span>
    # Chama função a ser testada</span></span>
    funcao2</span>(sqs_queue.client, sns_topic.client, sqs_queue.url, sns_topic.arn)</span></span>
</span>
    # Verifica se a função buscou e apagou as mensagens na fila do SQS</span></span>
    assert</span> len</span>(sqs_queue)</span> ==</span> 0</span></span>
</span>
    # Verifica se as respostas estão corretas no tópico SNS</span></span>
    assert</span> len</span>(sns_topic)</span> == len</span>(respostas)</span></span>
    assert</span> [</span></span>
        json.</span>loads</span>(msg[</span>'Message'</span>])</span> for</span> msg</span> in</span> sns_topic</span></span>
    ]</span> ==</span> respostas</span></span></code></pre>
Esse teste ficou muito mais simples, focando no que realmente importa para validar se o código está se comportando como deveria, e se aproveita de recursos do Python, como a função len</code></a> e compreensões de lista</a>. Toda a criação da fila SQS e tópico SNS se resumiu em adicionar as fixtures</em> sqs_queue</code> e sns_topic</code> como argumentos da função de teste, assim como sua remoção posteriormente.</p>
Quando precisa de múltiplos recursos do mesmo tipo</h2>
O teste anterior foi simples porque precisou de apenas um recurso de cada tipo. Porém se voltar a primeira função, aquela que recebe mensagens de uma fila SQS e envia o resultado para outra fila SQS, é necessário duas filas, mas a biblioteca entrega apenas uma fixture</em> que cria uma única fila SQS. Uma opção seria criar outras fixtures</em> para criar outras filas, porém quantas? Se criar poucas fixtures</em> continuaria faltando filas, se criar muitas elas seriam carregadas sem necessidade.</p>
Outra opção é dar um passo a traz, usando diretamente os contextos gerenciados em vez usá-los através de fixtures</em>. O código de teste fica um pouco mais poluído, com comandos para criar as filas, porém possibilita uma maior flexibilidade também, como: Criar mais de uma fila para o teste; Criar filas com nomes específicos (ou que o nome siga um determinado padrão); E controlar quando a fila será criada e removida (ao sair do contexto). Segue um exemplo do teste:</p>
import</span> json</span></span>
from</span> exemplo.codigo1</span> import</span> funcao1</span></span>
from</span> pytest_moto_fixtures.services.sqs</span> import</span> sqs_create_queue</span></span>
</span>
def</span> test_funcao1</span>(</span>sqs_client</span>):</span></span>
    # Mensagens com valores de entrada e resultados esperados</span></span>
    msgs</span> =</span> [</span></span>
        {</span>'n'</span>:</span> 0</span>},</span></span>
        {</span>'n'</span>:</span> 1</span>},</span></span>
        {</span>'n'</span>:</span> 2</span>},</span></span>
    ]</span></span>
    respostas</span> =</span> [</span></span>
        {</span>'resultado'</span>:</span> 0</span>},</span></span>
        {</span>'resultado'</span>:</span> 2</span>},</span></span>
        {</span>'resultado'</span>:</span> 4</span>},</span></span>
    ]</span></span>
</span>
    # Cria filas de teste</span></span>
    with</span> (</span></span>
        sqs_create_queue</span>(</span>sqs_client</span>=</span>sqs_client)</span> as</span> fila1,</span></span>
        sqs_create_queue</span>(</span>sqs_client</span>=</span>sqs_client)</span> as</span> fila2,</span></span>
    ):</span></span>
        # Envia mensagens de teste</span></span>
        for</span> msg</span> in</span> msgs:</span></span>
            fila1.</span>send_message</span>(</span>body</span>=</span>msg)</span></span>
</span>
        # Chama função a ser testada</span></span>
        funcao1</span>(sqs_client, fila1.url, fila2.url)</span></span>
</span>
        # Verifica se a função buscou e apagou as mensagens na fila1</span></span>
        assert</span> len</span>(fila1)</span> ==</span> 0</span></span>
</span>
        # Verifica se as respostas estão corretas na fila2</span></span>
        assert</span> len</span>(fila2)</span> == len</span>(respostas)</span></span>
        assert</span> [</span></span>
            json.</span>loads</span>(msg[</span>'Body'</span>])</span> for</span> msg</span> in</span> fila2</span></span>
        ]</span> ==</span> respostas</span></span></code></pre>Considerações finais</h2>
Esse texto apresentou uma sequência de passos e pensamentos que levaram até a criação da biblioteca pytest-moto-fixtures</a> para auxiliar na escrita de testes de código que utilizam serviços da AWS. Também apresentou como sua arquitetura foi surgindo das necessidades, sempre com o foco em simplificação, e como resolveu essas necessidades.</p>
A biblioteca também possui algumas facilidades que deixaram o código de teste bastante simples, como o uso das fixtures</em> para criação de recursos. Junto com o uso das funcionalidades da própria linguagem, isso permitiu um código de teste bastante simples e direto, sem precisar expor detalhes dos serviços utilizados. E para coisas mais complexas ou específicas, a biblioteca também permite utilizar manualmente algumas de suas camadas mais profundas, porém ainda assim de forma simplificada, sem sujar o código tanto quando sua versão sem o uso da biblioteca.</p>
Outra lição que fica é a possibilidade de criarmos bibliotecas para facilitar as coisas repetitivas do dia a dia, e não só usar as feitas por terceiros. Porém isso deve ser feito com estudo para realmente simplificar, caso contrário poderia trazer mais ou outras dificuldades para as atividades. Nessa forma, essa biblioteca seguiu a linha voltada para os testes de integração, outra biblioteca poderia surgir seguindo a ideia de uso de mocks</em>, possuindo características diferentes.</p>
Obs: O projeto com os códigos desse artigo pode ser acessado aqui</a>.</p>


Discussão sobre o Advent of Code 2023 - Dia 6: Modelando problema com matemática
2023-12-12T00:00:00+00:00
O problema do dia 6 do Advent of Code desse ano</a> pode ser resolvido usando matemática. Então resolvi testando o SymPy</a> e ver o quanto ele facilita nas análises e contas. O resultado encontra-se no seguinte notebook</a> (que também pode ser visualizado aqui</a>).</p>


Discussão sobre o Advent of Code 2022 - Dia 11: Complexidade de operações com números grandes
2023-03-19T00:00:00+00:00
No décimo primeiro dia do Advent of Code de 2022</a> tem um problema interessante para discutir sobre a complexidade de operações com números grandes.</p>
O problema do dia 11</h2>
O problema do dia 11, "macaco no meio"</a>, consiste em seguir uma sequência de passos, que pode ser implementada em código, para simular o ocorrido e calcular a resposta. Recomendo tentar resolvê-lo primeiro.</p>
Resolução da parte 1</h2>
Não existe nenhuma pegadinha na parte 1 do problema. Talvez a parte mais difícil possa ser ler a entrada, porém como o programa não precisa ser dinâmico, os dados dessa entrada podem estar fixos dentro do código, não sendo necessário ler o arquivo da entrada, simplificando o código. No demais é escrever um código que itere sobre os valores e tome as ações conforme descrito no problema.</p>
Resolução da parte 2</h2>
A parte 2 é igual à parte 1, mas com duas diferenças: o valor de preocupação com o item não é divido por 3 e devem ser calculado mais rodadas (passando de 20 para 10.000). Esses ajustes são simples de fazer no código, porém na hora de executar o programa ele fica calculando e não termina. O gráfico a baixo mostra o tempo que a solução que implementei leva para calcular cada rodada até a 135 no meu computador:</p>
</p>
No gráfico pode ser visto que as primeiras rodadas tiveram um tempo relativamente baixo, porém com o passar do tempo, aparecem picos cada vez mais altos, e os vales também estão subindo, ou seja, o tempo para se calcular uma nova rodada está crescendo conforme as rodadas foram passando. A pergunta que fica é porque isso ocorre se as operações são as mesmas e a quantidade de itens também não varia? O que está deixando o código mais lento?</p>
Bibliotecas para números grandes</h3>
Como eu fiz o meu programa em Python esse foi o comportamento do meu código, porém em outras linguagens poderia dar erro, ou até rodar relativamente rápido, mas apresentar resultados incorretos. Isso ocorre porque, como um valor manipulado pelo programa cresce, ele deixa de caber no espaço de uma variável de alguns bits (normalmente 16, 32, ou até 64 bits), ocorrendo um overflow</em> de inteiro</a>. Uma forma de lidar com isso é utilizando bibliotecas que consigam alocar mais espaço para as variáveis, e no Python, por exemplo, isso já é implementado nativamente. Mas por que fica cada vez mais lento?</p>
A pergunta que pode esclarecer o que está ocorrendo é: qual a complexidade de tempo para operações básicas (soma, subtração, multiplicação e divisão)? Para o tipo inteiro essas operações têm tempo constante (O(1)</code>), porém quando o valor deixa de caber num inteiro, usando o espaço de memória de múltiplos inteiros, essa operação deixa de ser contante. Imagine fazer a soma 139 + 183</code> manualmente, é possível começar somando as unidades (9 + 3</code>), depois as dezenas (3 + 8 + 1</code>, considerando o 1</code> a dezena da soma nas unidades), depois as centenas. Dessa forma é possível observar que quanto mais casas os números tiverem, mas operações precisam ser feitas, assim essa soma tem complexidade linear a quantidade de casas do valor (O(n)</code>). E embora o computador use os números em binário, essa lógica se repete para as bibliotecas que lidam com números grandes, mesmo operando um ou até quatro bytes por vez, só muda a base numérica. Então pelo fato dos valores não caberem mais em um número pequeno de bits a complexidade do algoritmo aumenta junto com o aumento dos valores.</p>
Reduzindo o valor a ser tratado</h3>
Porém ainda é necessário resolver a parte 2, e embora essas bibliotecas permitam com que o código execute corretamente, elas não fazem o mesmo rodar em tempo hábil. Então como isso pode ser feito? Aqui pode ser utilizado um pouco de matemática para evitar que os números cresçam de mais. Como o valor da preocupação utilizado no algoritmo não importa de fato, e sim o resto da divisão dele por outro número, isso pode ser utilizado para reduzir o valor da preocupação que o algoritmo precisa lidar, uma vez que os valores dessa operação ficam dentro de uma faixa menor e se repetem, mesmo que cresçam até o infinito, isso permite descartar parte da preocupação. Exemplo:</p>
0 % 4 == 0</span></span>
1 % 4 == 1</span></span>
2 % 4 == 2</span></span>
3 % 4 == 3</span></span>
4 % 4 == 0</span></span>
5 % 4 == 1</span></span>
6 % 4 == 2</span></span>
7 % 4 == 3</span></span>
8 % 4 == 0</span></span>
9 % 4 == 1</span></span>
...</span></span>
39 % 4 == 3</span></span>
40 % 4 == 0</span></span>
41 % 4 == 1</span></span>
...</span></span>
4000 % 4 == 0</span></span>
...</span></span></code></pre>
Porém a lógica apresentada considera apenas um único número (o 4</code> nesse exemplo). Para que isso possa ser aplicada para dois ou mais números é necessário encontrar um valor que possa dividir a preocupação de forma que esse ciclo continue se repetindo normalmente, da mesma forma que ocorreu no exemplo anterior. Uma forma simples de fazer isso é multiplicando todos as bases das divisões que o algoritmo precisa fazer, e toda vez que uma nova preocupação for calculada, basta guardar na variável o resto da divisão dela por esse valor calculado.</p>
Dessa forma os valores da preocupação não crescem até o infinito, e a parte 2 é calculada rapidamente.</p>
Considerações</h2>
Um algoritmo pode ter sua complexidade alterada apenas por ter que lidar com inteiros que podem estar além de uma quantidade fixa de bits. E não é eficiente aumentar essa quantidade de bits para todos os números, visto que se o processador não conseguir operar todos de uma vez, terá que fazer diversas operações para chegar no resultado, isso deixaria o código mais lento em sua execução e precisaria de mais memória, mesmo que os números não usem todos os bits disponíveis para a variável.</p>
Nesse texto foi considerado a multiplicação dos valores da base das divisões como fator para reduzir os valores da preocupação. Porém nem sempre ele será o valor mais otimizado, para ter a garantia de optimização desse fator pode ser utilizado o mínimo múltiplo comum</a> desses valores. Porém como no caso da minha entrada todos os valores eram primos, o mínimo múltiplo comum e a multiplicação dos valores da o mesmo resultado, não alterando o desempenho do código. E ainda sobre esse assunto, é interessante como uma representação gráfica desse ciclo do resto das divisões pode ser:</p>

    Tweet</a>
</blockquote>