O documento discute a importância de testes de contrato para garantir a compatibilidade entre serviços e aplicações conforme elas evoluem. Os testes de contrato validam se as mudanças em um serviço quebraram ou não os contratos estabelecidos com os clientes. Isso permite evoluir os serviços de forma incremental e controlada.
31. Outro time da empresa quer usar
sua listagem de produtos. Massa! :)
32. Outro time da empresa quer usar
sua listagem de produtos. Massa! :)
Estamos com pouco tempo. Compartilhe a
string de conexão do banco com o
pessoal, eles vão dar um jeito.
Gerente do
seu projeto:
33. Outro time da empresa quer usar
sua listagem de produtos. Massa! :)
Estamos com pouco tempo. Compartilhe a
string de conexão do banco com o
pessoal, eles vão dar um jeito.
Gerente do
seu projeto:
Melhor amigo: Além dos dados, tem código também. Crie
um jar file de produtos e manda por email.
34. Outro time da empresa quer usar
sua listagem de produtos. Massa! :)
Estamos com pouco tempo. Compartilhe a
string de conexão do banco com o
pessoal, eles vão dar um jeito.
Gerente do
seu projeto:
Melhor amigo: Além dos dados, tem código também. Crie
um jar file de produtos e manda por email.
35. Outro time da empresa quer usar
sua listagem de produtos. Massa! :)
Estamos com pouco tempo. Compartilhe a
string de conexão do banco com o
pessoal, eles vão dar um jeito.
Gerente do
seu projeto:
Melhor amigo: Além dos dados, tem código também. Crie
um jar file de produtos e manda por email.
você: =(
37. Serviço de
Produtos
Código e dados isolados
Acesso apenas via HTTP/Rest
Mas responsa-
bilidades estão
isoladas.
Times menores,
cuidando de
partes diferentes.
NÃO diminue a
complexidade
do sistema
como um todo.
(complexidade aumenta!)
41. • Repositórios (base de código) independentes
• Ferramentas de desenv. e suite de testes independentes
• Pipelines de build independentes
• Times mais ou menos independentes
• Time A (consumidor) depende de Time B (provedor)
47. Mudança =>
quebrando clientes
em produção
O site não tá mais abrindo!
Essa tela branca fica carregando pra sempre!
Meus dados sumiram?!
Não acontece nada quando eu aperto o botão!
49. Na verdade, a gente precisa
só da parte numérica..
Separar da unidade na mão
é muita gambiarra! =/
Tranquilo..
Mudo e faço
deploy! ;)“341ml” => “341”
50. Ei, tá maluco?
A gente já tá usando as
medidas com unidades!!
...
53. Se eu soubesse como
cada um tá usando
minha API...
Tô meio perdido..
54. Dá pra deixar claro o que
vocês querem?
Sério, preciso saber!
55. Relaxa, filhão..
A gente precisa de um
negócio assim:
“id” -> um número
“brand” -> uma string
“content” -> número também
56. Mas a gente usa as
unidades com as
medidas. Manda os
dois!!!
“id” -> um número
“brand” -> uma string
“content” -> número
“unit_of_measure -> string
57. Por mim.. Só
uso o id e o
nome..
“id” -> número
“brand” -> string
61. Meu pipeline
de build
commit
• Build
• Unit tests
• Functional (API level) tests
• Contract tests
• Deploy
• PROFIT $$$
Valido se os contratos dos meus
clientes estão sendo satisfeitos!
Agora eu sei quando uma mudança é
séria (breaking change)
62. Agora o pessoal fica tranquilo e
de boa quando eu aviso com
antecedência que vou deployar
uma breaking change..
Sei até os clientes que vão
quebrar e os que não vão!
Dá pra desenrolar as
mudanças aos incrementos,
eles vão se adaptando aos
poucos.
E não tem mais
essa de deploy do
cliente e serviço ao
mesmo tempo pra
não quebrar!!
63.
64. Se algo der errado, os testes
falham.. E não tem deploy.
75. JSON
Schema
Vamos testar mais rápido!!
Vamos usar mocks pros
nossos testes..
Mas vez ou outra a gente
valida o contrato na API de
verdade! ;)
Test
request
Resposta
mock
Test
request
API de
verdade
JSON
Schema