de usuário, ou caso de uso. Os testes de aceitação, são baseados em critérios de aceitação relacionados com regras de negócio que podem ser especificadas pelo Product
Owner.
É possível realizar testes de aceitação manualmente ou automatizá-los. A reali-
zação de testes manuais pode reduzir drasticamente a velocidade do time, por isso,
recomenda-se a automação dos testes.
Algumas ferramentas como o Selenium, por exemplo, permitem realizar a au-
tomação de testes de aceitação em aplicações web, gravando ações do usuário no
navegador para que o cenário possa ser reproduzido e os resultados verificados pos-
teriormente.
Vá além de testes exploratórios
Testes Manuais são testes realizados por pessoas, geralmente, que têm o papel
de testadores em um time de desenvolvimento de software. Alguns testes manuais
consistem basicamente na execução de um script escrito de antemão que possui uma
sequência de passos a serem seguidos e um resultado a ser validado. Esse tipo de teste pode ser facilmente automatizados.
72
Casa do Código
Capítulo 4. Entregando Valor
Há, porém, um segundo tipo de teste que é realizado manualmente, conhecido
como testes exploratórios. Eles se aproveitam de todos o potencial do testador para investigar e descobrir cenários, e possivelmente defeitos ou efeitos colaterais, que não haviam sido previstos anteriormente.
Para este tipo de testes não há um script preestabelecido e o testador vai muito
além do óbvio criando e adaptando sua abordagem ao longo do processo.
Lidando com Código Legado sem Cobertura de Testes
É muito comum que uma equipe que não trabalhava com métodos ágeis e passa
por uma transição se depare com um projeto para evoluir que não possui testes au-
tomatizados porque na cultura anterior testar e automatizar não era uma prática disseminada dentre os membros do time.
Fazer alterações em um sistema que não possui um bom conjunto de testes auto-
matizados é muito difícil. O maior risco é que você pode facilmente quebrar alguma
funcionalidade sem que ninguém perceba.
Por isso Michael Feathers e muitos outros agilistas consideram que código sem
cobertura de testes é código legado, não importa se foi escrito oito anos ou oito horas atrás [24].
Uma das opções para mudar essa cenário é melhorar a cobertura de testes pouco
a pouco a cada iteração. Para isso, Henrik Kniberg sugere o seguinte processo [35]: 1) Liste seus casos de testes.
2) Classifique cada teste por risco, o custo de se testar manualmente e o esforço para automatizar o teste (veja na figura 4.3.
3) Ordene por prioridade.
4) Automatize alguns testes a cada iteração, começando pelos casos de maior prio-
ridade.
73
4.2. Simplificando o Código com Refatoração
Casa do Código
Figura 4.3: Lista de Casos de Teste
Uma vez tendo a lista pronta e classificada é possível priorizar e começar pe-
los testes cuja falta apresenta maior risco, e que possuem maior custo de realização manual e menor custo de automação.
Quando não se tem testes automatizados a única forma de garantir que uma al-
teração não quebrou uma funcionalidade preexistente é realizando testes manuais.
Não é incomum que o custo de realizar os testes manualmente seja maior do que o
custo de automatizar, por isso pode ser interessante estimar e apresentar aos inte-
ressados no projeto para que possam entender o custo benefício do investimento na
automação deles.
Nem sempre temos a oportunidade de trabalhar em novos projetos em que po-
demos garantir alta cobertura de teste desde o princípio mas isso não é motivo para desanimar; pouco a pouco, iteração a iteração é possível mudar a realidade do projeto e melhorar a qualidade, aumentando a cobertura de testes.
4.2
Simplificando o Código com Refatoração
Complicar é fácil. Difícil é simplificar
Max Gehringer
É natural que ao longo do tempo a base de código de um sistema vá se tornando
74
Casa do Código
Capítulo 4. Entregando Valor
cada vez maior, assim como o número de funcionalidades disponíveis e a complexi-
dade do código fonte.
Sem boas práticas para manter o código limpo e organizado, à medida que mais
código vai sendo acrescentado, mais desorganizado e difícil de se compreender o
repositório vai se tornando. Isso impacta negativamente na produtividade dos de-
senvolvedores que encontrarão mais dificuldade em dar manutenção nas funciona-
lidades existentes e em adicionar novas funcionalidades.
Qualquer idiota pode escrever código que um computador pode entender. Bons
programadores escrevem código que seres humanos podem entender.
Martin Fowler
Refatorar é alterar a estrutura do código sem alterar o seu comportamento. É
uma prática que permite que o desenvolvedor melhore o design do código, tornando-
o mais limpo e fácil de se compreender. É uma técnica essencial para prevenir que o código se deteriore [20].
Mas para que o desenvolvedor possa alterar o código com segurança de que o
comportamento não será alterado, é essencial que o código possua uma boa base
de