Testes de Contrato — A motivação
O porquê dessa estratégia de teste ser tão valiosa para uma equipe.
Este é o Primeiro Post da série: Testes de Contrato utilizando Python
O objetivo deste post (e dos próximos) é apresentar uma introdução sobre testes de contrato e um exemplo real para estruturar um projeto de testes de contrato. Durante a leitura deste e dos outros posts da série, você aprenderá alguns conceitos básicos, mas recomendo que você procure ler outros materiais para se aprofundar no assunto e entender tudo o que testes de contrato pode te oferecer.
Alguns links para leitura:
Testes de Contrato por Martin Fowler.
Testes de Contrato utilizando PACT.
Testes de Contrato por Maarten Groeneweg (entrevista InfoQ).
Série de posts sobre Pact e Testes de Contrato da Zup.
Testes de contrato é uma estratégia utilizada para poder avaliar a qualidade dos contratos que foram previamente acordados entre duas partes, vou chamá-las de cliente e parceiro. Por que eu escolhi o nome parceiro? Porque atualmente encontramos muitos projetos que acabam utilizando serviços externos, para executar certas demandas que não podem ou não serão desenvolvidas pela equipe do projeto. Desta forma, meu projeto se torna “cliente” e o serviço que eu preciso acessar se torna meu “parceiro”. Este parceiro irá disponibilizar endpoints que você e seu projeto irão consumir. Vale ressaltar que nem sempre o fornecedor será alguém externo, é possível que exista acordos entre o backend e o frontend, dentro de um mesmo projeto na empresa.
Times ágeis geralmente estão preocupados em realizar validações em seus projetos, criam estratégias de teste para o backend e frontend, tanto funcionais quanto não funcionais. Porém, quem valida o parceiro? Alguém fica preocupado em monitorar os endpoints que foram disponibilizados? Será que o parceiro não erra? Empresas grandes que possuem alta demanda de clientes nem sempre conseguem avisá-los sobre mudanças em seus endpoints ou, não atualizam sua documentação de API’s.
No seu projeto, você e sua equipe já pararam para pensar se o formato das responses está sendo mantido durante as interações?
Podemos fazer um exercício mental: E se o serviço foi contratado em janeiro, vocês desenvolveram em cima dele e, por ironia do destino, essa parte da sua aplicação não foi mais revisada até o momento da produção, que ocorreu em junho? De janeiro a junho é possível que alguma manutenção tenha sido realizada, você não foi avisado, não leu a documentação do endpoint, e o que pode estar acontecendo? Simplesmente talvez sua aplicação não esteja mais recebendo informação no formato que era esperado. Até alguém do time perceber que o problema está em um serviço externo e não na aplicação, posso afirmar com confiança, que algumas horas serão gastas.
Ou o pior, o endpoint externo está fora do ar. Status Code 500
Então, para tentar prever “pequenos imprevistos” os testes de contrato entram como aliados do seu time e do projeto. Com essa estratégia, você poderá ficar monitorando continuamente o parceiro do projeto e, a qualquer mudança, você poderá questionar os envolvidos, evitando qualquer surpresa no futuro. Inclusive com essa prática, será possível descobrir se o endpoint parceiro possui instabilidades (fora do ar e por quanto tempo). Interessante, não?
Não tenha medo de validar serviços externos. Questione o que não fizer sentido.
Bom, agora que você já sabe um pouco da motivação em utilizar testes de contrato, podemos seguir para a próxima etapa, onde irei apresentar uma forma de começar com testes de contrato utilizando Python (validando endpoints do Spotify). Porém, se você ainda não conhece python requests ou até mesmo a web API do Spotify, recomendo fortemente que você leia primeiro 2 artigos (artigo A e artigo B) que eu escrevi sobre este assunto.
Caso você tenha ficado com alguma dúvida até agora, fique a vontade para deixar um comentário ou entrar em contato comigo.
Até o próximo post ;)
