Baixado 10 vezes
Carregado porRafael Portela
Evoluindo Apps e Serviços com Testes de Contrato
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.
Evoluindo Apps e Serviços com Testes de Contrato
- 1. Evoluindo App´s eServiços com Testes de Contrato @rafaelportela
- 2.
- 3. NO GRITO sobre aarte de lidar com complexidade
- 4. NO GRITO sobre aarte de lidar com complexidade Don´t you know that´s toxic?
- 5. CONFLITO Mais pessoas Mais times Maiscomplexidade
- 6. CONFLITO Mais pessoas Mais times Maiscomplexidade
- 7.
- 10. Validate bank accounts 3-D Secure Auth Money transfer Login List items Seedetails Comment Like Add Card Pay Moderate users Back end Moderator Bank Android iOS web
- 14. Time 1 Time 2 Time3 Time 4 Time 5
- 15. Time 1 Time 2 Time3 Time 4 Time 5
- 16. Time 1 Time 2 Time3 Time 4 Time 5
- 17. Time 1 Time 2 Time3 Time 4 Time 5
- 18. Time 1 Time 2 Time3 Time 4 Time 5
- 19. Time 1 Time 2 Time3 Time 4 Time 5
- 20. Time 1 Time 2 Time3 Time 4 Time 5
- 21. Time 1 Time 2 Time3 Time 4 Time 5
- 22.
- 23.
- 24.
- 25.
- 26. problema? DEPENDÊNCIA discutir funcionalidades priorizar tarefas dependênciade serviços deploys sincronizados
- 27. problema? DEPENDÊNCIA discutir funcionalidades priorizar tarefas dependênciade serviços deploys sincronizados contrato
- 28. Outro exemplo: <insiraSEU projeto aqui> Você e seu time estão desenvolvendo uma aplicação maneira (web, ou mobile, ou uma api etc)
- 29. O projeto cresce. Otime cresce. O estresse cresce.
- 30. O projeto cresce. Otime cresce. O estresse cresce. Módulo de Produtos
- 31. Outro time daempresa quer usar sua listagem de produtos. Massa! :)
- 32. Outro time daempresa 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 daempresa 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 daempresa 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 daempresa 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 edados isolados Acesso apenas via HTTP/Rest
- 37. Serviço de Produtos Código edados 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 TimeA Provedor do serviço Servidor Time B
- 40. GET /products/1 Accept: application/json 200OK Content-Type: application/json {“id”: 1,“name”: “beer”} REQUEST RESPONSE
- 41. • Repositórios (basede 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 Deploytodo dia
- 44. { “id”: 1, “name”: “DuffBeer”, “content”: “341ml” } GET /products/1
- 45. { “id”: 1, “name”: “DuffBeer”, “content”: “341ml” }
- 46. { “id”: 1, “brand”: “DuffBeer”, “content”: “341ml” }
- 47. Mudança => quebrando clientes emproduçã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, agente 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? Agente já tá usando as medidas com unidades!! ...
- 51. Pra mim, tudocerto! Eu só uso o nome e id. ...
- 52.
- 53. Se eu soubessecomo cada um tá usando minha API... Tô meio perdido..
- 54. Dá pra deixarclaro o que vocês querem? Sério, preciso saber!
- 55. Relaxa, filhão.. A genteprecisa de um negócio assim: “id” -> um número “brand” -> uma string “content” -> número também
- 56. Mas a genteusa 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ó usoo 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 pessoalfica 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 dererrado, os testes falham.. E não tem deploy.
- 65.
- 66.
- 67.
- 68.
- 69. Queremos mais umas mudanças! Beleza! Atualizemos contratos com as mudanças, e então eu acerto.
- 70.
- 71. JSON Schema • Build • Unittests • Functional (API level) tests • Contract tests pull request contrato
- 72. JSON Schema • Build • Unittests • Functional (API level) tests • Contract tests pull request contrato Atualizo o código, implemento o que elas querem
- 73. JSON Schema • Build • Unittests • Functional (API level) tests • Contract tests • Deploy • PROFIT $$$ pull request contrato commit Atualizo o código, implemento o que elas querem
- 74.
- 75. JSON Schema Vamos testar maisrá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.
- 77.
- 78.