6. Test-Driven Development
● Escreva um teste (unitário) para a funcionalidade que você deseja
○ O teste irá falhar, afinal a funcionalidade ainda não existe!
● Escreva o código da funcionalidade até que o teste passe
○ Utilize baby steps!
● Refatore o código
○ A ideia é deixá-lo bem estruturado!
7. Estranho ou não?
● Começar exige um certo esforço
● A prática leva a naturalidade
● Se você achou difícil, está tudo bem
8. Mas porquê é importante?
● Te ajuda a moldar o design da aplicação
● Dá mais confiabilidade e qualidade a aplicação
● Torna melhor a manutenção do código (para refatorar ou corrigir bugs)
14. O menor teste possível
Dado um nome, retorna o gênero.
entrada: Ana
saída: female
15. O menor teste possível
Dado um nome, retorna o gênero.
Utilizando
pytests!
16. O menor teste possível
Dado um nome, retorna o gênero.
Utilizando
pytests!
AAA: Arrange, Act & Assert
17. O menor teste possível
Dado um nome, retorna o gênero.
Utilizando
pytests!
18. Importante!
● AAA
○ Arrange: prepare tudo o que você precisa para executar o seu teste
○ Act: execute o trecho de código a ser testado
○ Assert: verifique o resultado!
● Os testes devem estar em uma pasta separada
○ Por convenção, o nome da pasta é chamada de tests
● Os arquivos de testes devem começar com o prefixo
test_nome_do_modulo_testado.py
○ As bibliotecas de teste buscam pelo prefixo test_
● Os nomes dos testes importam e precisam ser expressivos!
○ Os testes devem ser a documentação viva do código
22. Situações que poderiam existir no “detector”
● Retornar “female” quando o nome for feminino
● Retornar “male” quando o nome for masculino
● Buscar apenas pelo primeiro nome
● Lançar uma exceção quando o nome for “” ou None
● Retornar “unidentified” quando o nome não tiver o gênero identificável
23. Continuando o menor teste possível
Dessa vez, dado um nome masculino, retorna o gênero “male”.
Utilizando
pytests!
27. Quais as desvantagens da nossa abordagem atual?
● Tempo de execução
● Os testes não são offline
● Não atende as limitações do negócio
○ Muitas APIs, assim como essa, tem número de requests limitadas
30. Algumas regras de ouro sobre Mocks
● Mock o que você não pode testar
● Mock dependências externas
● Evite mockar as suas classes
○ Mockistas x Classistas
40. Pra lembrar!
● A maior vantagem do TDD é deixar surgir o design do software
○ Buscando melhor manutenção e objetividade
● Qualidade do código / manutenibilidade
○ A garantia após fazer uma alteração: não tem preço
● Começar pode ser difícil - e está tudo bem - pratique!
41. Para Casa
● Test Driven Development: By Example
● Growing Object-Oriented Software, Guided by Tests
● Dar uma olhada:
○ Continuous Integration
○ Continuous Delivery
○ Cobertura de testes
● Código da palestra completo em:
github.com/anapaulagomes/in-tests-we-trust