Evoluindo Apps e Serviços com Testes de Contrato
•Transferir como PPTX, PDF•
2 gostaram•898 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Evoluindo Apps e Serviços com Testes de Contrato
Semelhante a Evoluindo Apps e Serviços com Testes de Contrato (20)
Último
Último (11)
Evoluindo Apps e Serviços com Testes de Contrato
- 1. Evoluindo App´s e Serviços com Testes de Contrato @rafaelportela
- 2. Você Vestindo a camisa do projeto seu Chefe Ajudando como pode
- 3. NO GRITO sobre a arte de lidar com complexidade
- 4. NO GRITO sobre a arte de lidar com complexidade Don´t you know that´s toxic?
- 5. CONFLITO Mais pessoas Mais times Mais complexidade
- 6. CONFLITO Mais pessoas Mais times Mais complexidade
- 7. contrato consumer-driven contracts testes de contrato
- 10. Validate bank accounts 3-D Secure Auth Money transfer Login List items See details Comment Like Add Card Pay Moderate users Back end Moderator Bank Android iOS web
- 14. Time 1 Time 2 Time 3 Time 4 Time 5
- 15. Time 1 Time 2 Time 3 Time 4 Time 5
- 16. Time 1 Time 2 Time 3 Time 4 Time 5
- 17. Time 1 Time 2 Time 3 Time 4 Time 5
- 18. Time 1 Time 2 Time 3 Time 4 Time 5
- 19. Time 1 Time 2 Time 3 Time 4 Time 5
- 20. Time 1 Time 2 Time 3 Time 4 Time 5
- 21. Time 1 Time 2 Time 3 Time 4 Time 5
- 22. problema?
- 26. problema? DEPENDÊNCIA discutir funcionalidades priorizar tarefas dependência de serviços deploys sincronizados
- 27. problema? DEPENDÊNCIA discutir funcionalidades priorizar tarefas dependência de serviços deploys sincronizados contrato
- 28. Outro exemplo: <insira SEU projeto aqui> Você e seu time estão desenvolvendo uma aplicação maneira (web, ou mobile, ou uma api etc)
- 29. O projeto cresce. O time cresce. O estresse cresce.
- 30. O projeto cresce. O time cresce. O estresse cresce. Módulo de Produtos
- 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ê: =(
- 36. Serviço de Produtos Código e dados isolados Acesso apenas via HTTP/Rest
- 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!)
- 39. Consumidor do serviço Cliente Time A Provedor do serviço Servidor Time B
- 40. GET /products/1 Accept: application/json 200 OK Content-Type: application/json {“id”: 1,“name”: “beer”} REQUEST RESPONSE
- 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)
- 42. Deploy a cada 2 semanas Deploy todo dia
- 44. { “id”: 1, “name”: “Duff Beer”, “content”: “341ml” } GET /products/1
- 45. { “id”: 1, “name”: “Duff Beer”, “content”: “341ml” }
- 46. { “id”: 1, “brand”: “Duff Beer”, “content”: “341ml” }
- 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!
- 48. Sou sempre o último a saber
- 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!! ...
- 51. Pra mim, tudo certo! Eu só uso o nome e id. ...
- 52. Time A Time B
- 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
- 58. um objeto json { “id”: 1, “brand”: “Duff Beer”, “unit_of_measure”: “ml”, “content”: 341 } inteiro inteiro string
- 59. { “properties”: { “id”: {“type”: “integer”}, “brand”: {“type”: “string”}, “unit_of_measure”: {“type”: “string”}, “content”: {“type”: “integer”} } } JSON Schema
- 60. Meu pipeline de build commit • Build • Unit tests • Functional (API level) tests • Contract tests • Deploy • PROFIT $$$
- 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!!
- 64. Se algo der errado, os testes falham.. E não tem deploy.
- 67. BONUS TRACK
- 69. Queremos mais umas mudanças! Beleza! Atualizem os contratos com as mudanças, e então eu acerto.
- 71. JSON Schema • Build • Unit tests • Functional (API level) tests • Contract tests pull request contrato
- 72. JSON Schema • Build • Unit tests • Functional (API level) tests • Contract tests pull request contrato Atualizo o código, implemento o que elas querem
- 73. JSON Schema • Build • Unit tests • Functional (API level) tests • Contract tests • Deploy • PROFIT $$$ pull request contrato commit Atualizo o código, implemento o que elas querem
- 74. BONUS TRACK
- 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
- 76. SATISFACTION