TDD com Python

Testes
Versão Python
Osvaldo Santana Neto
osantana@triveos.com
Sunday, October 24, 2010

Osvaldo Santana Neto
Programador amador
desde 1988
Programador proﬁssional
desde 1991
Programador Python
desde 2000
Programador Django
desde 2008

Teste automatizado
... é o uso de software para controlar a
execução dos testes.

Testes automatizados
Unitários
Integração
Funcionais
Aceitação
Regressão
Outros: performance, estático, performance,
segurança, ...

Unitário
Inventory

Unitário
Unitário
Inventory
Order
Integração
DB

Funcionais
Unitário
Unitário
Inventory
Order
Integração
DB

Prós
Asseguram uma
qualidade maior no
código
Garante que os
sistemas continuem
funcionando após
mudanças
Contras
Não garatem que o
código é "bug free"
Tempo de
desenvolvimento e
manutenção de
aplicação tem um
pequeno aumento

No longo prazo sempre trazem benefícios
Quando usar?
para testar código que já existe
antes de iniciar uma refatoração
durante o processo de bugﬁx
antes de implementar o código (usado para guiar a
implementação) — Test-Driven Development

Cobertura de código
Desejável 100%
Não existe ferramenta capaz de medir com 100% de
certeza a cobertura
Código 100% coberto != código sem bugs
Ferramenta: coverage.py

Test-Driven Development
Desenvolvimento guiado por testes

Abreviação: TDD
Kent Beck: prática de
XP e depois em seu
livro Test-Driven
Development by
Examples
Utilização de testes
unitários na condução
do desenvolvimento
traduzido

TDD não é "ensinado".
TDD é "praticado"
Na fase de treinamento
é importante seguir as
regras. Depois
podemos quebrá-las.
Baby Steps

Uma linha de código só existe se tiver um teste a
avaliando
Altos índices de cobertura: >90%

Red. Green. Refactor.
Escrever um
teste que falha
Fazer o
teste passar
Refatorar

Red.
Escrever um teste que inevitavelmente falhe
Se o teste não falhar?
A nova funcionalidade já existe e,
consequentemente, já deve ter sido testada.
Mantê-lo é opcional mas se não tivermos
segurança para removê-lo é melhor mantê-lo.
Teste com problema

Green.
Escrever o mínimo de código que faça o teste passar
"Fake It ('Til you make it)" — valores 'hard coded' ou
objetos "fakes" no lugar de dependências ainda não
implementadas
Triangulate — implementação real quando você tem
dois ou mais exemplos
"Obvious Implementation ('Til you get red bars)" —
implementações óbvias podem ser feitas

Refactor.
Refatoração:
Aperfeiçoar o código
sem alterar o seu
comportamento
Remover duplicação
de código entre o
código implementado
e o teste
traduzido

Testes unitários
Teste de uma unidade de código

Testes unitários
Unidades de código: funções, métodos, classes, ...
System Under Test (SUT) — código que está sendo
testado
Framework xUnit: unittest, nose e py.test
Criado por Kent Beck para Smalltalk e
posteriormente para Java (jUnit)
Doctests — documentação "executável"

Testes unitários
Ferramentas Python — http://j.mp/ptRk
Unit Test e Runners: unittest, doctest, nose, py.test, ...
Mockery: mocker, pyMock, pMock, Mock, mox, ...
Functional/Acceptance: selenium, windmill, pyccuracy,
twirl, django-client, ...
Static: pylint, pyﬂakes, pychecker, ...
Coverage: coverage

Testes unitários
Usaremos:
Ambiente virtual isolado: virtualenv
Unit Test e Runners: unittest e nose
Mockery: mocker
Functional/Acceptance: selenium
Coverage: coverage

Testes unitários
Existe a possibilidade de usar outras ferramentas para
os casos:
Unittest e Runners: py.test
Mockery: Mock
Neste caso os exemplos precisarão ser feitos "na mão"

Testes unitários
Etapas:
Setup (setUp) — preapara o ambiente onde o teste
será executado (ﬁxtures)
Exercise (test*) — executa o procedimento a ser
testado
Assert (assert*/verify) — veriﬁca os resultados
Teardown (tearDown) — limpa o ambiente

Testes unitários
Dicas
O melhor "primeiro teste" é o teste que veriﬁca o
caso de uso mais comum. O teste mais básico.
Comece a escrever pelas "assertions"

Testes unitários
Características
Isolamento — testes são independentes
Legibilidade — devem privilegiar legibilidade
Velocidade — devem executar rapidamente
Manutenabilidade — manutenção deve ser fácil
Não intrusivos — código de teste deve ﬁcar somente
no teste e não no SUT

Testes unitários
Isolamento
Um teste devem funcionar de forma independente
de outros testes e assumir um ambiente "limpo" para
execução
Todas as dependências do código testado devem
ser subtituídas por "doubles" (fakes/stubs ou mocks)
Mocks aren't Stubs - Martin Fowler
http://bit.ly/mockrnstubs

Testes unitários
Legibilidade
O código do teste não precisa ser elegante, precisa
ser legível. Testes são para "consumo" humano
Resultados esperados em primeiro lugar:
Pior Melhor
banco = Banco()
banco.indice("USD", "BRL", TAXA_PADRAO)
banco.comissao(COMISSAO_PADRAO)
res = banco.converte(
Nota(100, "USD"), "BRL)
assert res == Nota(49.25, "BRL")
banco = Banco()
assert Nota(49.25, "BRL") == res

Testes unitários
Legibilidade
Dados evidentes: deixe a relação entre as entradas e
os resultados aparente:
Pior Melhor
banco = Banco()
assert Nota(49.25, "BRL") == res
banco = Banco()
banco.indice("USD", "BRL", 2.00)
banco.comissao(0.015)
assert Nota(100 / 2 * (1 - 0.015), "BRL")
== res

Testes unitários
Legibilidade
Nome de teste: test_(pass|fail)_descricao_(invalid|
with_x|without_y|basic)
Apenas 1 ciclo setup/exercise/verify/teardown por
teste
A legibilidade sempre é subjetiva mas é importante
estabelecer padrões em projetos desenvolvidos por
equipes com vários desenvolvedores

Testes unitários
Dicas
O ciclo completo de red/green/refactor deve ser
curto para privilegiar o ritmo.
Se o teste está ﬁcando grande: quebre-o em testes
menores

Testes unitários
Dicas
Programando sozinho? Deixe o último teste
"quebrado" no ﬁm de uma sessão de programação
para saber de onde retomar o desenvolvimento
Programando em equipe? Faça 'commit' somente
se todos os testes estiverem passando
Usa um sistema de controle de versão distribuído?
Deixe 'quebrado' localmente

Testes unitários
Testabilidade
Fácil testar: código bem desenhado, código criado
com TDD, funções determinísticas, etc
Difícil testar: GUI, código assíncrono, esquemas em
banco de dados, componentes de aplicações
distribuídas, funções não-determinísticas, etc
Existem práticas e padrões que tornam alguns
tipos de testes mais fáceis de serem feitos

Padrões com objetos falsos
Test Double Patterns

Exemplo de código

Exemplo de código
Dependência

Testes falham

Testes falham
FALHAM!

Test Double
Substituir uma ou mais dependências do SUT por um
equivalente especíﬁco para o teste:
Test Double
Dummy
Object
Test
Stub
Test Spy
Mock
Object
Fake
Object

Dummy
Geralmente são valores que não são usados no teste.
Algumas vezes são apenas passados como
parâmetros para atender ao número de parâmetros de
um método.

Fake
Uma implementação funcional do objeto original

Stubs
Similares aos objetos Fake
Não tem uma implementação funcional, apenas
retorna valores pré-estabelecidos
Podem gerar uma exceção para testar comportamento
do SUT nessa situação
Ex: Simular um erro de timeout na conexão com um
banco de dados

Spy
Similares aos objetos Stub
Registram chamadas para seus métodos para que seja
possível fazer uma veriﬁcação indireta posteriormente
Ex. Servidor de e-mail que registra e-mails "enviados"

Mock
Tipo especial de objeto que pode ser programado com
as expectativas de chamadas e retornos

Mock
Rede de objetos
Fonte: Growing Object-Oriented Software, Guided by Tests

Mock
Testando objeto
isoladamente

Mock
Testando com um
objeto mock

Mocker
http://labix.org/mocker
Desenvolvida pelo brasileiro Gustavo Niemeyer
Usa a estratégia Record (para especiﬁcar as
expectativas e retornos) & Play (para veriﬁcar os
resultados)

Mock
Mocker

Padrões para banco de
dados
Database Patterns

Padrões de banco de dados
Database Sandbox — cada desenvolvedor tem um
banco de dados à sua disposição (ex. Django SQLite in
memory)
Table Truncate Teardown — truncar as tabelas na fase
do teardown
Transaction Rollback Teardown — iniciar uma
transação na fase de setup e efetuar um rollback na
fase de teardown. Deve-se cuidar para que não tenha
nenhum commit no SUT

Padrões de desenho para
testabilidade
Design-for-Testability Patterns

Padrões para testabilidade
Dependency Injection — permite substituir
dependências do SUT por Test Doubles.
A dependência pode ser passada na construção ou
como parâmetro do método.
Ex. O objeto TimeDisplay depende de TimeProvider
que, nos testes, é substituído por stub/mock
Dependency Lookup — o objeto busca suas
dependências em um local especíﬁco. Ex. registro, dict

Padrões para testabilidade
Humble object — extrair a lógica num componente
separado e mais fácil de testar.
Ex. extrair a parte síncrona de um objeto com
operações assíncronas
Pode-se usar um método no lugar de um objeto
Test Hook — não use: adicionar lógica condicional no
SUT para se comportar de modo especíﬁco com os
testes
Exemplo!
pag. 764 do xunit

Desenvolvendo aplicações
Desenvolvendo aplicações completas usando

Testes de aceitação
Validar requisitos dos
clientes
Selenium2,
Pyccuracy, Windmill,
Django Client, etc.
Inicia ciclo red/green/
refactor

Escrever um
teste que falha
Fazer o
teste passar
Refatorar
Escrever um
teste de aceitação
que falha

Escrever um
teste que falha
Fazer o
teste passar
Refatorar
Escrever um
teste de aceitação
que falha
Se surgir alguma idéia
nova para outro teste:
anote no papel

Resumo
Sumário dos tópicos abordados

Resumo
Testes são isolados
A ordem dos testes não é garantida
Não se deve adicionar lógica de teste no código de
produção
Testes devem assumir um ambiente limpo quando
começam e limpar o ambiente quando terminam

Resumo
red / green / refactor
setup, exercise, verify, teardown

F.A.Q.
Quando sei que os testes são suﬁcientes?
Quando você tiver certeza que seu software está
completo e sem bugs: nunca serão.
Quando eu preciso fazer testes:
Resposta curta: sempre. Resposta longa: quando
você não tiver segurança total daquilo que precisa
ser feito

F.A.Q.
Qual o tamanho ideal de um baby-step?
Resposta curta: do tamanho que te dê segurança.
Resposta longa: TDD é uma prática e como tal
requer treino. O ideal é que no início se use passos
pequenos e posteriormente aumentá-los.
Existe uma relação direta entre a cobertura de testes e
a quantidade de bugs num código?
Existe essa relação mas ela não é linear.

Mensagens
Teste é algo desejável num software. Melhor se forem
automatizados e ótimos se o código foi feito depois do
teste
Falácia: "Código não testado é código bugado"
Não existe bala de prata, logo, teste automatizado
não é uma delas
Atenção para os "radicais do teste". Radicalismo
nunca é bom para um programador

Leitura complementar
Não terminamos por aqui...

Leitura Complementar
Internet
TDD @ Wikipedia — http://j.mp/zBGgt
Mocks aren't Stubs — http://j.mp/7MdzF
Inversion of Control and Dependency Injection —
http://j.mp/I0YAA

Leitura Complementar

TDD com Python

Mais conteúdo relacionado

Mais procurados

Semelhante a TDD com Python

Mais de Osvaldo Santana Neto

TDD com Python