Os debates sobre mono e multi repos geralmente são focados no código das aplicações, mas e quanto ao repositório de teste?

Este artigo aborda este tema, analisando as opções possíveis de repositório e de armazenamento dos nossos testes, ligados as nossas aplicações.

Assumimos aqui que seus arquivos de configuração de teste estão acessíveis para armazená-los em um repositório.

Como preâmbulo, pode consultar este artigo Os principais modelos de Monorepo e Multirepo que precisa de conhecer.

Junta-se a QE Unit para aceder a mais conteúdos exclusivos a comunidade.

Por que manter nossos testes em um repositório?

Vamos inverter a questão, o que acontece sem um repositório de nossos testes?

Cada membro da equipe armazenará seus arquivos de teste, o que pode criar vários problemas de curto e médio prazo:

• Duplicação de casos de teste
• Inexistência de módulos de teste
• Perda de arquivos nos vários armazenamentos
• Conflito de alterações dos mesmos testes
• Incapacidade de uso os testes na ausência de um colaborador
• Perda de tempo em pesquisa, compartilhamento e uso

Podemos fazer melhor por nossos testes, que são ativos reais das nossas empresas.

Geralmente, eles devem ser armazenados utilizando um mecanismo durável, seguro, com controle de versão, acessível e sustentável.

A necessidade de portabilidade também pode ser relevante, para manter o controle de seu repositório de teste fora de uma ferramenta específica, dando mais flexibilidade para mudanças.

Uma vez devidamente centralizado, é possível oferecer suporte ao compartilhamento e à colaboração em torno de seus testes, resolvendo alguns dos problemas identificados.

Os mecanismos de versionamento de software também são portadores de processos que melhoram a qualidade de nossos testes, como de peer review apoiada por merge request Git.

Também tem acesso facilitado ao histórico, capacidade de reversão, gerenciamento de conflitos para uma colaboração estendida.

A escolha de mono ou multi-repos também se aplica aos testes?

Os nossos arquivos de teste são armazenados em uma estrutura de árvore definida, geralmente agrupados no conceito do projeto.

Portanto, temos a mesma escolha de organização em mono ou multi-repositórios para nossos testes, com as mesmas vantagens e desvantagens.

Da mesma forma, os diferentes arquivos podem ser organizados conforme nossa conveniência dentro de um repo, sua atribuição a um repositório sendo um outro nível de granularidade.

Para os testes, adicionamos a variante da ligação ao código do aplicativo: devemos manter nossos testes com nossos aplicativos?

Quais alternativas entre código e repositórios de teste?

Temos duas opções possíveis para cada situação encontrada.

A primeira é manter nossos testes com o código de nossa aplicação dentro do mesmo projeto, como um único mono-repo, que chamaria de single mono repo.

A segunda alternativa será manter nossos testes em um projeto separado, seja no mesmo repositório ou num outro.

Pelas vantagens e desvantagens de cada solução, entendemos a importância do contexto e em aceitarmos seus limites.

Quais critérios de decisão usar?

O contexto atual e suas possíveis evoluções são os primeiros elementos a esclarecer para articular sua tomada de decisão.

Os nossos objetivos irão destacar os pontos que mais valorizamos ao aceitar as limitações de um modelo.

Fique tranquilo, normalmente não precisamos de uma matriz de decisão complicada.

Como na vida cotidiana, normalmente precisamos de 3 argumentos para nos inclinarmos para uma alternativa específica.

Aqui estão as escolhas que enfrentamos:

• Devemos manter nossos testes dentro de nossa aplicação?
• Devemos usar um mono ou multi-repos para nossos testes?

Duas escolhas são necessárias para nossos repositórios de testes: mono ou multi repos, mono ou multi projetos.

Antoine Craske

Já podemos proceder por eliminação com os testes de unidade que devem ser armazenados com o projeto para serem integrados ao ciclo de build.

Por outro lado, podemos armazenar código e testes separadamente se quisermos manter as nossas pipelines de construção livres de exclusões de pasta de teste ou outros conflitos.

Levar em consideração o contexto organizacional é para mim uma prioridade mais importante que considerações técnicas.

Se a equipe de QA não estiver familiarizada com uma gestão distribuída de branching, versionamento e modelos de colaboração, a separação de código e testes é preferível para não impactar os fluxos de desenvolvimento, enquanto devem ser treinados.

Temos que considerar o modelo organizacional atual e futuro que queremos incentivar, não se limitando apenas ao controle de qualidade.

Um único repo de código e testes para uma empresa promove visibilidade, colaboração e compartilhamento multifuncional, ao custo de gerenciar um único repo.

Esse modelo pode ser adequado para empresas que buscam esses objetivos, com uma cultura mais centralizada do que descentralizada, seja uma start-up ou um grande grupo como o Google.

Podemos ter como objetivo acelerar os desenvolvimentos em paralelo por pequenas unidades com as diferentes funções presentes. Nesse caso, um modelo multi-repos deixará a liberdade de incluir ou não os testes nos projetos de aplicação.

Nossos critérios de decisão estão fortemente ligados à cultura, comportamento e modelos de entrega que queremos alcançar, apoiados por um nível mais ou menos forte de coupling dos ciclos de entrega.

Que boas práticas aplicar?

As boas práticas permanecem válidas independentemente do modelo escolhido.

Uma visão holística das equipes, da organização atual e futura nos guiará na escolha e evolução dos repositórios.

Limitar a complexidade às necessidades iniciais permitirá que iterações mais rápidas para criar valor. Manter as possíveis evoluções em mente nos permitirá manter alguma margem de manobra.

Por exemplo, querer muito rapidamente configurar um modelo completo de multi-repos para Dev e QA acaba sendo arriscado para uma organização que não está alinhada e que falta de maturidade colaborativa.

Os fundamentos da convenção de nomenclatura e de controle de versão são estruturantes em todos os modelos, facilitando a localização de projetos de teste vinculados a projetos de desenvolvimento, por exemplo.

Ter um ciclo de vida, repositório e modelo de ramificação semelhante entre o código e o teste é desejável para facilitar a compreensão, alinhamento e manutenção.

Os repositórios de QA requerem organização real

A escolha de mono e multi-repos é, portanto, também estruturante para artefatos de QA.

Alguém também pode se perguntar se há uma diferença real na escolha entre o código do aplicativo e os testes.

Do ponto de vista local, estamos de fato lidando com arquivos de texto cujo ciclo de vida tem de ser organizados.

Por outro lado, o desempenho, a facilidade e a compreensão da integração de projetos de QA impactam o processo de desenvolvimento e sua performance, daí a necessidade de manter essa perspectiva mais ampla.

É com uma visão holística de um sistema que podemos alinhar as escolhas locais para obter mais benefícios globais.