Tag: testes unitários

Atualmente, realizar testes funcionais automatizados já é uma realidade para a maioria das empresas. Muitas empresas buscam profissionais com essa habilidade para construir testes robustos, que consigam detectar problemas antes da aplicação ir para produção. Mas os Testes de Aceitação, Testes de Regressão, Smoke Tests, Testes de API e Testes de UI representam respectivamente uma parte da pirâmide de testes. E a dúvida que fica é: estamos dando atenção para as demais camadas? Nesse artigo, vou dar a minha visão para a distribuição de testes da uma aplicação baseada na construção de uma Pirâmide de Testes robusta. O que é uma Piramide de Testes? A piramide de testes original de Mike Cohn A Pirâmide de Testes é um modelo que descreve a distribuição ideal dos diferentes tipos de testes em um projeto. Essa representação gráfica tem como objetivo orientar na estruturação de suas estratégias de teste e garantir uma cobertura eficaz de qualidade do software. Em sua concepção, a Pirâmide de Testes foi criada com 3 camadas sendo: Testes Unitários Testes de Serviços Testes de UI E nessa disposição da pirâmide, entende-se que: Quanto mais perto da base: Mais testes devem ser criados Execução mais rápida, pois os testes são realizados em partes menores da aplicação Quanto mais perto do topo Menos testes devem ser criados Execução mais lenta, já que os componentes testados já possuem muitas integrações Porém, dada a arquitetura de software que adotamos atualmente, a pirâmide de testes de Mike Cohn acaba tendo uma visão bem simplista, e por isso precisamos revistar esse modelo para que se adeque as necessidades do nosso projeto. Agora que entendemos o que é uma Piramide de Testes e a necessidade de revisitá-la, vamos montarm uma boa pirâmide. Montando uma Pirâmide de Testes Bom, para montarmos uma Pirâmide, precisaremos de um exemplo de uma arquitetura simples, mas que seja proximo do nosso cotidiano, para termos como base. Veja a imagem abaixo: Na imagem acima, vamos nos limitar a exercitar uma funcionalidade imaginária de Pesquisa de Pedido de Venda. E nela temos: O Frontend Web e o Frontend Mobile solicitando dados de um pedido de venda, por meio de um Get no endpoint /orders de um BFF O BFF (Backend For Frontend) que por sua vez, solicita informações do pedido de venda por meio de um Get no endpoint /orders do Orders API, para que possa formartar as informações com base naquilo que o Frontend espera. E o Orders API, que é uma API Rest que tem a responsabilidade de manter os pedidos de venda. Com esse exemplo em mente e focando apenas nos blocos em verde, a piramide ideal (ao meu ver) seria a ilustrada abaixo: De baixo para cima, vamos entender cada uma dessas camadas. Testes Unitários Os Testes Unitários podem ser aplicados tanto na camada de apresentação quanto na camada de negócio. A escolha de onde aplicar os testes unitários depende da arquitetura e da estratégia de teste adotada no projeto. A camada de negócios (onde estão BFF e principalmente o Orders API, no nosso exemplo) é geralmente uma área crítica para aplicar testes unitários. Isso ocorre porque é nessa camada que a lógica de negócios essencial é implementada. Testar essa camada garante que as regras de negócios estejam corretas e que a aplicação funcione conforme o esperado em termos de funcionalidades de negócios. Quanto à camada de apresentação (onde está o Front Web, no nosso exemplo), geralmente envolve interações com a interface do usuário e a exibição de dados. Testes unitários podem ser úteis aqui, especialmente se houver lógica de apresentação complexa. Testes Integrados Os Testes Integrados podem ser aplicados para validar as integrações com outros serviços ou partes externas à aplicação, como um Banco de Dados ou tópico do Kafka, por exemplo. Por serem fatores externos à aplicação que está sendo testada, normalmente essas integrações são mockadas, seja criando um mock para um serviço específico simulando uma resposta exata para a necessidade do teste (casos do Front Web e BFF), ou levantando um banco em memória com dados que atendam as necessidades dos testes criados, para validar uma consulta ao banco e retorno dos dados (caso do Orders API), por exemplo. Esses testes são comumente deixados para as camadas de teste de Serviço ou de UI. Porém, trazendo esses testes para a camada de testes integrados, teremos um feedback muito mais rápido, e consequentemente uma rápida correção e reexecução em casos que problema sejam detectados. Testes de Contrato Os Testes de Contrato podem ser aplicados para validar a comunicação entre as aplicações. Tanto na visão de quem provê uma determinada informação (Provedor), quanto de quem consome a informação para poder seguir com seu fluxo (Consumidor). Esses testes não possuem como objetivo validar o comportamento da aplicação em teste quando recebe um dado vindo de uma parte de fora, isso os Testes Integrados já fazem. Aqui o importante é saber se as duas partes, Consumidor e Provedor conseguem estabelecer uma comunicação baseado em um contrato firmado, e com isso atencipar a detecção de falhas dessa categoria antes da execução dos testes das camadas de Serviço e UI. Testes de API Os Testes de End to End de API, ou somente Testes de API, permitem que possamos testar todos os fluxo de negócio de um serviços em um ambiente similar ao de produção evitando a utilização da interface gráfica e suas conhecidas instabilidades. Como a aplicação está em um ambiente apartado, longe da máquina do desevolvedor, e também possui todas as suas integrações e comunicações validadas pelos Testes Integrados e Testes de Contrato respectivamente, precisamos levar testes mais críticos para essa camada, para evitar duplicação massiva de testes. A ideia não é refazer todos os testes da camada de integração, obivamente alguns irão se repetir, mas o escopo tende a ser cenários mais críticos para o negócio. Aqui, o Robot Framework, pode entrar para ajudar na criação desses testes. Testes de UI Os Testes End To End de Inteface Gráfica, ou somente Testes de UI, permitem que fiquemos mais próximos a forma como o usuário irá se comportar com a aplicação, portanto, o foco passa a ser esse. Meclar os cenários levantados com a forma como o usuário irá manusear a interface gráfica. Portanto, o escopo aqui é bastante reduzido já que todas as camadas de testes anteriores garante o pleno funcionamento do negocio, integração e comunicação da aplicação. Aqui, o Robot Framework também ajudará bastante. Monitorar também é importante Tão importante quanto as camadas de testes da piramide, é também conseguir monitorar o ambiente de produção e entender as falhas que ocorrem com os usuário. E com esse monitoramento poderemos entender novos cenários e criar novos testes em sua respectiva camada para que diminuir o risco de reincidência da mesma falha. O mesmo vale para falhas ainda na esteira de desenvolvimento. Se um erro foi detectado em uma camada superior (Testes de API, por exemplo), um ou mais testes precisarão ser criados nas camadas de baixo (Testes de Integração e Unitário) para evitar a recorrência do erro pela mesma causa. Mas isso já é um papo sobre Testes Contínuos, que iremos abordar aqui no blog futuramente. Conclusão Existe uma diversidade de tipos de testes que podem ser encorporadas à sua estratégia de testes e que ajudarão demais na garantia de qualidade da sua aplicação. Os Testes de Widgets (para Front Mobile), ou até mesmo os Testes de Mutação (para verificar a eficiencia dos testes unitários) poderiam também compor essa pirâmide, mas preferi deixá-las de fora para esse post não ficar grande demais. Mas ideia principal desse post é fazer com que você olhe para outras partes da arquitetura do seu projeto e consiga identificar camadas de testes onde você e sua equipe podem atuar além dos testes unitários e testes de UI e API. E lembre-se, ter uma pirâmide bem definida é um trabalho bem árduo, e leva tempo para ser maturada. Mas no final é bastante recompensador. Espero que esse artigo te ajude! Grande Abraço...Valeu! The Testing Pyramd na Robot Store Adquira a camisa "The Testing Pyramid" na Robot Store. Sua compra ajudará demais na continuação desse projeto.

Solverwp- WordPress Theme and Plugin