[Sugestão] Estratégias de Testes: Diferenciando Testes Unitários e Automatizados em Ambientes de Desenvolvimento e CI/CD

No contexto do curso, quando é mencionado o termo "testes automatizados", entendo que o conceito mais adequado aos testes apresentados em aula seria o de testes unitários (ou testes de unidade). Isso ocorre porque estamos verificando componentes individuais de forma isolada, utilizando ferramentas como o JUnit 5 em conjunto com o Mockito para simular dependências e garantir que as unidades de código se comportem como esperado.

Entretanto, na prática de mercado, o termo "testes automatizados" abrange um escopo mais amplo. Ele geralmente se refere a testes que são projetados para serem executados de forma contínua em uma pipeline de CI/CD (Continuous Integration/Continuous Deployment). Esses testes automatizados podem incluir diferentes níveis, como testes de integração, testes de sistema e testes de aceitação. O objetivo principal é assegurar a qualidade do software de ponta a ponta, além de gerar relatórios detalhados, como a cobertura de testes enviada para ferramentas como o SonarQube.

Por exemplo, ferramentas como o Cucumber são amplamente utilizadas para escrever cenários de teste em formato BDD (Behavior-Driven Development). Essa abordagem permite que testes automatizados sejam mais legíveis e compreensíveis para stakeholders técnicos e não técnicos. No Cucumber, os cenários de teste são escritos em linguagem Gherkin, permitindo uma descrição clara e humanizada dos comportamentos esperados do sistema.

É importante destacar que testes unitários e testes automatizados mais amplos não se excluem, mas se complementam. Os testes unitários são essenciais para garantir a qualidade no nível de componentes individuais, enquanto os testes automatizados de integração ou aceitação asseguram que os diferentes módulos funcionem bem juntos e atendam aos requisitos funcionais e não funcionais.

Por fim, práticas recomendadas sugerem que:

Testes unitários devem ser executados localmente por desenvolvedores durante o ciclo de desenvolvimento.
Testes automatizados de nível superior devem ser integrados à esteira de CI/CD para garantir qualidade contínua.
A cobertura de código deve ser acompanhada por ferramentas como SonarQube, mas sempre analisada de forma crítica, já que cobertura alta não garante ausência de bugs, mas sim maior confiança no código testado.

Essas práticas proporcionam uma estratégia abrangente de testes que ajuda a entregar software de alta qualidade, alinhado aos objetivos do projeto e às expectativas do cliente.

Olá Matheus!

Você levantou um ponto muito interessante sobre a distinção entre testes unitários e testes automatizados em um contexto mais amplo, como em pipelines de CI/CD. Vamos explorar um pouco mais isso.

Testes Unitários: Como você mencionou, eles são focados em testar componentes individuais de forma isolada. Utilizando ferramentas como JUnit 5 e Mockito, você pode simular dependências e verificar se cada unidade de código se comporta conforme o esperado. Isso é essencial para garantir que cada parte do seu código está funcionando corretamente antes de integrá-la com outras partes do sistema.

Testes Automatizados em CI/CD: Em um ambiente de integração contínua e entrega contínua, os testes automatizados vão além dos testes unitários. Eles podem incluir testes de integração, que verificam a interação entre diferentes módulos, testes de sistema, que testam o sistema como um todo, e testes de aceitação, que garantem que o sistema atende aos requisitos do cliente. Ferramentas como o Cucumber são úteis aqui, permitindo que você escreva testes em um formato que seja legível tanto para desenvolvedores quanto para stakeholders não técnicos.

Na prática, uma boa estratégia de testes em um ambiente de CI/CD incluiria:

Execução de Testes Unitários Localmente: Antes de qualquer commit, os desenvolvedores devem rodar testes unitários para garantir que suas alterações não quebrem o código existente.
Testes Automatizados no Pipeline de CI/CD: Assim que o código é commitado, ele deve passar por uma série de testes automatizados que podem incluir testes de integração e de sistema. Isso ajuda a identificar problemas que podem não ser evidentes em testes unitários isolados.
Cobertura de Código: Ferramentas como SonarQube podem ajudar a monitorar a cobertura de testes, mas é importante lembrar que uma alta cobertura não garante a ausência de bugs. É mais uma medida de confiança no código testado.

Por exemplo, em um projeto Java, você poderia configurar seu pipeline de CI/CD para rodar testes unitários com JUnit e Mockito, e testes de integração usando Cucumber para cenários mais complexos. Isso garantiria que tanto as unidades individuais quanto o sistema como um todo estão funcionando conforme o esperado.

Espero ter ajudado e bons estudos!