Bom, vamos falar um pouco mais sobre os testes de software. Como havíamos comentado anteriormente, os testes de software têm um papel fundamental dentro do CSD, que é através dele, principalmente, que vamos conseguir medir e mensurar, isso como qualidade, como resiliência, se a gente está inserindo algum bug, se a gente conseguiu atender as funcionalidades do nosso stakeholder. E para isso, existem algumas metodologias disponíveis no mercado, que é o que vamos falar um pouco mais agora. A primeira delas é o Test Driven Development, que é uma abordagem de desenvolvimento em que todos os testes são inscritos antes mesmo do código de produção. O ciclo típico de TDD envolve três etapas. O REG, onde o desenvolvedor escreve o teste automatizado que define um comportamento desejado ou uma funcionalidade que ainda não existe no sistema. Esse teste inicialmente falha, pois o código de produção correspondente ainda não foi implementado. A segunda etapa é o Green, onde escrevemos um código mínimo necessário para fazer o teste passar. O objetivo aqui é implementar apenas o suficiente para satisfazer o teste recém-criado. Defector. Após passar o teste, o desenvolvedor pode refatorar o código para melhorar a sua qualidade, sem alterar seu comportamento observável. E esse ciclo é repetido interativamente, com o desenvolvedor escrevendo novos testes para novas funcionalidades ou alterações no código existente. A segunda abordagem é o Behavior Driven Development, ou BDD, que se concentra no comportamento esperado do sistema em vez de nas implementações específicas. Ela promove uma colaboração mais estreita entre os desenvolvedores, testers e stakeholders, utilizando uma linguagem comum para descrever o comportamento do sistema em termos de cenários de usuário. Os cenários de usuários são escritos em uma linguagem natural, compreensível por todas as partes interessadas, geralmente usando uma estrutura como Given, When, Then ou Dado, Quando, Então. Vamos ver um exemplo. Dado que o usuário esteja na página de login, quando ele inserir um nome de usuário e senha, então ele deverá ser redirecionado para a página inicial. Esse é um teste típico, utilizando o BDD, por exemplo. Em seguida, esses cenários de usuários são traduzidos em testes automatizados, geralmente utilizando alguma ferramenta de BDD, como um Cucumber, por exemplo. Então, em resumo, enquanto o TDD se concentra na escrita de testes antes do código estar em produção, para facilitar a manutenção e garantir a qualidade do código, o BDD é mais focado na descrição do comportamento do sistema em termos de cenário de usuário, tornando compreensíveis por todas as partes interessadas e derivamos testes automatizados a partir desses cenários. Bom, então como havíamos comentado em aulas anteriores, existem N técnicas e N tipos de testes automatizados que podemos explorar e quando a gente fala de DevOps, quando a gente fala de esteiras de CISD, diversas dessas técnicas são amplamente exploradas. Então vamos passar por algumas delas. A primeira são os testes unitários. Os testes unitários verificam se unidades individuais de código, geralmente funções ou métodos, funcionam corretamente de forma isolada. Elas são mais rápidas de executar e fornecem feedback sobre a correção do código. Testes integrados. Os testes integrados verificam se diferentes componentes do sistema funcionam corretamente juntos. Eles podem incluir testes de API, testes de banco de dados e testes de integrações entre sistemas. Testes end-to-end. Os testes end-to-end simulam um fluxo completo de interações de um usuário com o sistema, verificando se todas as partes do sistema funcionam corretamente juntas. Elas são úteis para garantir que as funcionalidades críticas para o usuário final estejam funcionando conforme esperado. Testes regressivos. Os testes regressivos garantem que as alterações no código não quebrem funcionalidades existentes. Elas são executadas automaticamente sempre que há uma nova implantação ou alteração no código. Testes sintéticos. Os testes sintéticos simulam o comportamento do usuário final em um ambiente de produção, ajudando a identificar problemas de desempenho e disponibilidade antes que afetem os usuários reais. Elas são especialmente úteis para monitorar serviços críticos e garantir que a gente esteja dentro dos nossos SLAs. Testes mutantes. Os testes mutantes modificam o código-fonte de forma controlada para verificar que os testes automatizados conseguem detectar essas alterações. Elas ajudam a identificar lacunas nos conjuntos de testes existentes e melhorar a cobertura de teste de uma forma geral. Testes contínuos. Os testes contínuos são executados automaticamente em cada etapa da pipeline de um CI-CD, garantindo que o código seja testado continuamente durante o processo de desenvolvimento e implantação, e garantem que não tenhamos problemas, que os problemas sejam identificados e corrigidos o mais cedo possível. E por fim, teste de matriz. Uma matriz de testes é uma abordagem para organizar e gerenciar diferentes conjuntos de testes para garantir uma cobertura abrangente. Ela identifica as combinações de plataformas, navegadores, dispositivos e outras variáveis, garantindo que todas as configurações críticas sejam testadas. Esses tipos de testes automatizados são essenciais para uma adoção bem-sucedida de práticas DevOps, garantindo a qualidade, confiabilidade e a segurança do software, enquanto de forma rápida e consistência. Esses tipos de testes automatizados são essenciais para a adoção bem-sucedida de práticas DevOps, garantindo a qualidade, confiabilidade e segurança do software entregue, de forma rápida e consistente. Eu imagino que muitos de vocês já estejam familiarizados com esses tipos de teste, principalmente quando a gente fala de teste unitário, teste integrado, o pessoal utiliza com bastante frequência, existem diversas ferramentas no mercado que nos auxiliam para a gente conseguir passar principalmente por esses dois tipos de teste alguns outros são um pouquinho menos comuns, mas eu acho que o principal aqui, a mensagem que tem que ficar é que quando a gente fala de DevOps e até de SRE os testes tem um papel fundamental já que a gente consegue cada vez mais e com cada vez mais testes e técnicas diferentes de testes, conforme a gente coloca isso dentro de uma esteira de pipeline, a gente estressa cada vez mais o nosso software e passa a ter uma qualidade, passa a ter um grau de confiabilidade de que aquilo que a gente está levando para a produção é muito maior. Inclusive, alguns desses testes a gente consegue fazer pós-implementação. Então, por exemplo, vamos supor que a gente faça o deployment de uma imagem, de repente será uma API e como que a gente consegue teve todos os testes unitários passou por tudo ali em desenvolvimento e homologação os testes integrados a mesma coisa mas pode ser que por algum motivo não sei, por falta de algum teste ou alguma coisa que acabou passando quando a gente levou isso para a produção a gente percebeu que os health checks passaram com sucesso, foi tudo implementado com sucesso, mas a gente está tendo algum tipo de erro funcional e isso está impactando os usuários. Num cenário como esse, se a gente tivesse testes sintéticos sendo executados pós implementação dessa aplicação em produção, ainda dentro da pipeline a gente conseguiria mitigar esse tipo de problema. Então, esse é só um dos exemplos que eu posso citar aqui que a gente conseguiria alavancar e meu olha a diferença que a gente já conseguiria trazer é num cenário como