tizar todo o processo de postos de gasolina. O sistema deveria tomar conta de todo
o fluxo: desde a comunicação com as bombas de gasolina, liberando ou não o abas-
tecimento, até relatórios de fluxo de caixa e quantidade de combustível vendido por
dia ou por bomba.
A aplicação era desenvolvida inteira em C e deveria rodar em um micro-
dispositivo de 200MHz de processamento e 2MB de RAM. Nós éramos em 4 de-
senvolvedores, onde todos programavam e todos testavam ao mesmo tempo. Os
testes não eram tão simples de serem feitos, afinal precisávamos simular bombas de
1.2. Por que devemos testar?
Casa do Código
gasolinas, abastecimentos simultâneos, e etc. Mas, mesmo assim, nos revezávamos
e testávamos da forma que conseguíamos.
Após alguns meses de desenvolvimento, encontramos o primeiro posto disposto
a participar do piloto da aplicação. Esse posto ficava em Santo Domingo, capital da
República Dominicana.
Eu, na época líder técnico dessa equipe, viajei para o lugar com o objetivo de
acompanhar nosso produto rodando pela primeira vez. Fizemos a instalação do pro-
duto pela manhã e acompanhamos nosso bebê rodando por todo o dia. Funcionou
perfeitamente. Saímos de lá e fomos jantar em um dos melhores lugares da cidade
para comemorar.
Missão cumprida.
1.2
Por que devemos testar?
Voltando do jantar, fui direto pra cama, afinal
no dia seguinte entenderíamos quais
seriam as próximas etapas do produto. Mas às 7h da manhã, o telefone tocou. Era o
responsável pelo posto de gasolina piloto. Ele me ligou justamente para contar que
o posto de gasolina estava completamente parado desde as 0h: o software parou de funcionar e bloqueou completamente o posto de gasolina.
Nosso software nunca havia sido testado com uma quantidade grande de abaste-
cimentos. Os postos em Santo Domingo fazem muitos pequenos abastecimentos ao
longo do dia (diferente daqui, onde enchemos o tanque de uma vez). O sistema não
entendeu isso muito bem, e optou por bloquear as bombas de gasolina, para evitar
fraude, já que não conseguia registrar as futuras compras.
O software fez com que o estabelecimento ficasse 12h parado, sem vender nada.
Quanto será que isso custou ao dono do estabelecimento? Como será que foi a reação
dele ao descobrir que o novo produto, no primeiro dia, causou tamanho estrago?
Os Estados Unidos estimam que bugs de software lhes custam aproximadamente
60 bilhões de dólares por ano [34]. O dinheiro que poderia estar sendo usado para
erradicar a fome do planeta está sendo gasto em correções de software que não fun-
cionam.
É incrível a quantidade de software que não funciona. Pergunte ao seu amigo
não-técnico se ele já ficou irritado porque algum programa do seu dia a dia simples-
mente parou de funcionar. Alguns bugs de software são inclusive famosos por todos:
o foguete Ariane 5 explodiu por um erro de software; um hospital panamenho matou
pacientes pois seu software para dosagem de remédios errou.
2
Casa do Código
Capítulo 1. Introdução
1.3
Por que não testamos?
Não há um desenvolvedor que não saiba que a solução para o problema é testar seus
códigos. A pergunta é: por que não testamos?
Não testamos, porque testar sai caro. Imagine o sistema em que você trabalha
hoje. Se uma pessoa precisasse testá-lo do começo ao fim, quanto tempo ela levaria?
Semanas? Meses? Pagar um mês de uma pessoa a cada mudança feita no código
(sim, os desenvolvedores também sabem que uma mudança em um trecho pode
gerar problemas em outro) é simplesmente impossível.
Testar sai caro, no fim, porque estamos pagando a pessoa errada para fazer
o trabalho. Acho muito interessante a quantidade de tempo que gastamos criando
soluções tecnológicas para resolver problemas dos outros. Por que não escrevemos
programas que resolvam também os nossos problemas?
1.4
Testes automatizados e TDD
Uma maneira para conseguir testar o sistema todo de maneira constante e contínua
a um preço justo é automatizando os testes. Ou seja, escrevendo um programa que
testa o seu programa. Esse programa invocaria os comportamentos do seu sistema e
garantiria que a saída é sempre a esperada.
Se isso fosse realmente viável, teríamos diversas vantagens. O teste executaria
muito rápido (afinal, é uma máquina!). Se ele executa rápido, logo o rodaríamos
constantemente. Se os rodarmos o tempo todo, descobriríamos os problemas mais
cedo, diminuindo o custo que o bug geraria.
Um ponto que é sempre levantando em qualquer discussão sobre testes manuais
versus testes automatizados é produtividade. O argumento mais comum é o de que
agora a equipe de desenvolvimento gastará tempo escrevendo código de teste; antes
ela só gastava tempo escrevendo código de produção. Portanto, essa equipe será
menos produtiva.
A resposta para essa pergunta é: o que produtividade? Se produtividade for me-
dida através do número de linhas de código de produção escritos por dia, talvez o
desenvolvedor seja sim menos produtivo. Agora, se produtividade for a quantidade