Garantindo a qualidade da sua API REST com Behave

Globalcode – Open4education
Garantindo a qualidade da sua API
REST com Behave
Alex S. Garzão
Projetista de Software
Yuri Z. Pinheiro
Analista de Qualidade
ZAP Imóveis
www.linkedin.com/in/alexgarzao/ www.linkedin.com/in/yurizp

Agenda
• Nosso contexto
• Projeto, desafios, problemas e soluções
• O que é BDD
• O que é Behave
• Nossa proposta
• Demonstração
• Resultados
• Lições aprendidas
• Próximos passos

Vamos nos conhecer
• Testes automatizados. Quem aqui utiliza?
• BDD. Quem conhece? Quem utiliza?
• Behave. Quem conhece? Quem utiliza?

Nosso contexto no ZAP
• Desenvolvemos API RESTful
• Python
• Django
• MySQL

Primeiros desafios
• Regras de negócio instáveis
• Definição do escopo em andamento
• Entendimento do projeto não era claro
• Novas tecnologias na empresa

O que isso ocasionou?
• Baixa qualidade de código (Bugs a rodo)
• Retrabalho do time
• Time desmotivado

Qual a solução?
• Testes, obviamente
• Começamos com testes manuais
• Mas isso não escala
• Tester virou gargalo da equipe
• Vamos automatizar :-)

Em busca de soluções
● Aplicação em Python
○ É possível, mas partiríamos do zero :-/
● Curl
○ Fácil para testes pontuais
● Postman
○ Legal, mas a automação dele é trabalhosa
● Robot framework
○ Técnico demais
● Lettuce
○ Legal, mas foi descontinuado
● Behave

O que é o BDD?
• Técnica de desenvolvimento ágil
• Encoraja interação entre técnicos e “não técnicos”
• Foco no negócio, e não nos detalhes técnicos
• Exemplos descrevem o comportamento da
aplicação
• São executáveis (documentação viva)
• São testes regressivos

Fluxo com BDD
Fonte: http://www.qualister.com.br/blog/o-que-e-atdd---acceptance-test-driven-development

O que é o Behave?
• Utilizado para a prática de automação de testes
• Open source
• Suporte para BDD em Python
• Permite a escrita de cenários de teste
• Linguagem próxima a “natural”

Exemplo Behave - Calcular fatorial
Funcionalidade: Calcular o fatorial
Cenário: Fatorial de 0
Dado eu tenho o número 0
Quando eu calculo este fatorial
Então eu vejo o número 1

Funcionalidade: Calcular o fatorial
@given(u'eu tenho o número {number}')
def step_impl(context, number):
context.number = int(number)
@when(u'eu calculo este fatorial')
def step_impl(context):
context.number = factorial(context.number)
@then(u'eu vejo o número {expected}')
def step_impl(context, expected):
expected = int(expected)
assert context.number == expected

• Métodos de uma API Rest
• Exemplo: Rota para cadastro de imóveis
• Endpoint: https://api.meusite.com/imoveis
• JSON: {
proprietario: "fulano de tal",
endereco: "Rua A, 520",
valor: 450000
}
O que queríamos testar?

Oh shit!
• Behave é uma ferramenta genérica
• Não entende API RESTful
• HTTP? JSON? GET/POST/PUT/DELETE?
• Endpoint? Request? HTTP status code?

Nossa proposta...
• Ferramenta open source
• Utilizando o Behave
• Permite a escrita de testes automatizados
• Entende o que é uma API RESTful
• Cenários de testes são executáveis
• Escritos em português

Tentativa 1 - O início de tudo...

Esquema do Cenário: Como usuário tento cadastrar imóveis
Dado que eu quero cadastrar um imóvel
E o proprietário é <nome> e o endereço é <endereço> e o
valor é <valor>
Quando eu tento cadastrar o imóvel
Então eu recebo o código 200
Exemplos: Dados válidos para imóveis
| nome | endereço | valor |
| Proprietário 01 | Rua A POA RS | 1000.00 |
| Proprietário 02 | Rua B POA RS | 2000.00 |
• Step confuso de entender
• Steps muito específicos
• Reutilização engessada
• A cada novo step, uma nova implementação

Tentativa 2

Esquema do Cenário: Como usuário tento cadastrar imóveis
E o proprietário é <nome>
E o endereço é <endereço>
E o valor é <valor>
Então eu recebo o código 200
• Maior reutilização :-)
• Melhor legibilidade
• A cada novo step uma nova implementação :-(

Hoje - Steps genéricos

Esquema do Cenário: Como usuário quero cadastrar imóveis
E o campo nome do proprietário é <nome>
E o campo endereço do imóvel é <endereço>
E o campo valor do imóvel é <valor>
Então eu recebo o status que indica imóvel criado
• Não temos mais steps específicos por campo
• Utilizamos alias (apelidos) para campos, códigos de status,
endpoints, ...

Como são definidos os “alias”?

E listas?

Cenário: Como usuário quero listar meus imóveis
Dado que eu quero listar os meus imóveis
Quando eu busco a lista de imóveis
Então eu recebo o status que indica requisição válida
E obtenho a lista de dados abaixo
| nome do proprietário | endereço do imóvel |
| Proprietário 01 | Rua A POA RS |
| Proprietário 02 | Rua B POA RS |
• Validamos tipagem
• Validamos só os campos necessários
• Onde está o valor?

E dados não previsíveis?

Como enviamos nulo e vazio em
requisições?

E quando precisamos de dados
variáveis?

Demonstração

Resultados
• Fomos
• De poucos testes manuais para 90% de cobertura
(testes automatizados)
• Ganho de tempo
• Temos testes sendo executados a todo momento
• Para cada novo bug temos um cenário de teste
• Facilidade em desenvolver novos testes

Resultados
• Confiança na qualidade
• Confiança para realizar alterações críticas
• Qualquer pessoa, técnica ou não, consegue
desenvolver novos cenários

Lições aprendidas
• Tempo para girar a roda é alto
• Dependência de API’s externas? Mock
• Setup dos dados no início dos testes
• Criar o banco, inserir dados de configuração, ...
• Não usar dados fictícios
• Rodar os testes em homologação
• Em produção é um plus
• Feature deve ser independente
• Cenário independente melhor ainda!

Próximos passos
• Pacote instalável via pip
• Disseminar o BDD
• Mande sua sugestão :-)

Referências
• Livro BDD in Action:
https://www.manning.com/books/bdd-in-action
• Projeto: https://github.com/alexgarzao/victory
• Behave: http://pythonhosted.org/behave/

Perguntas?

Garantindo a qualidade da sua API REST com Behave

Mais conteúdo relacionado

Semelhante a Garantindo a qualidade da sua API REST com Behave

Garantindo a qualidade da sua API REST com Behave