de linhas de código de produção sem defeitos escritos por dia, provavelmente o de-
senvolvedor será mais produtivo ao usar testes automatizados.
Além disso, se analisarmos o dia a dia de um desenvolvedor que faz testes manu-
ais, podemos perceber a quantidade de tempo que ele gasta com teste. Geralmente o
3
1.5. Conclusão
Casa do Código
desenvolvedor executa testes enquanto desenvolve o algoritmo completo. Ele escreve
um pouco, roda o programa, e o programa
falha. Nesse momento, o desenvolve-
dor entende o problema, corrige-o, e em seguida executa novamente o mesmo teste.
Quantas vezes por dia o desenvolvedor executa o mesmo teste manual? O desenvol-
vedor que automatiza seus testes perde tempo apenas 1 vez com ele; nas próximas, ele
simplesmente aperta um botão e vê a máquina executando o teste pra ele, de forma
correta e rápida.
1.5
Conclusão
Minha família inteira é da área médica. Um jantar de fim de semana em casa parece
mais um daqueles episódios de seriados médicos da televisão: pessoas discutindo
casos e como resolvê-los. Apesar de entender praticamente nada sobre medicina,
uma coisa me chama muito a atenção: o fanatismo deles por qualidade.
Um médico, ao longo de uma cirurgia, nunca abre mão de qualidade. Se o paci-
ente falar para ele: Doutor, o senhor poderia não lavar a mão e terminar a cirurgia
15 minutos mais cedo?, tenho certeza que o médico negaria na hora. Ele saberia que
chegaria ao resultado final mais rápido, mas a chance de um problema é tão grande,
que simplesmente não valeria a pena.
Em nossa área, vejo justamente o contrário. Qual desenvolvedor nunca escreveu
um código de má qualidade de maneira consciente? Quem nunca escreveu uma
gambiarra"? Quem nunca colocou software em produção sem executar o mínimo
suficiente de testes para tal?
Não há desculpas para não testar software. E a solução para que seus testes sejam
sustentáveis é automatizando. Testar é divertido, aumenta a qualidade do seu pro-
duto, e pode ainda ajudá-lo a identificar trechos de código que foram mal escritos
ou projetados (aqui entra a prática de TDD). É muita vantagem.
Ao longo do livro, espero convencê-lo de que testar é importante, e que na ver-
dade é mais fácil do que parece.
4
Capítulo 2
Testes de Unidade
2.1
O que é um teste de unidade?
Imagine-se passeando em uma loja virtual qualquer na web. Ao selecionar um pro-
duto, o sistema coloca-o no seu carrinho de compras. Ao finalizar a compra, o sis-
tema fala com a operadora de cartão de crédito, retira o produto do estoque, dispara
um evento para que a equipe de logística separe os produtos comprados e te envia
um e-mail confirmando a compra.
O software que toma conta de tudo isso é complexo. Ele contém regras de negó-
cio relacionadas ao carrinho de compras, ao pagamento, ao fechamento da compra.
Mas, muito provavelmente, todo esse código não está implementado em apenas um
único arquivo; esse sistema é composto por diversas pequenas classes, cada uma com
sua tarefa específica.
Desenvolvedores, quando pensam em teste de software, geralmente imaginam
um teste que cobre o sistema como um todo. Um teste de unidade não se preocupa
com todo o sistema; ele está interessado apenas em saber se uma pequena parte do
sistema funciona.
2.2. Preciso mesmo escrevê-los?
Casa do Código
Um teste de unidade testa uma única unidade do nosso sistema. Geralmente, em
sistemas orientados a objetos, essa unidade é a classe. Em nosso sistema de exemplo,
muito provavelmente existem classes como CarrinhoDeCompras, Pedido, e assim
por diante. A ideia é termos baterias de testes de unidade separadas para cada uma
dessas classes; cada bateria preocupada apenas com a sua classe.
2.2
Preciso mesmo escrevê-los?
Essa mesma loja virtual precisa encontrar, dentro do seu carrinho de compras, os
produtos de maior e menor valor. Um possível algoritmo para esse problema seria
percorrer a lista de produtos no carrinho, comparar um a um, e guardar sempre a
referência para o menor e o maior produto encontrado até então.
Em código, uma possível implementação seria:
public class MaiorEMenor
{
public Produto Menor { get; private set; }
public Produto Maior { get; private set; }
public void Encontra(CarrinhoDeCompras carrinho)
{
foreach(Produto produto in carrinho.Produtos)
{
if(Menor == null || produto.Valor < Menor.Valor)
{
Menor = produto;
}
else if (Maior == null ||
produto.Valor > Maior.Valor)
{
Maior = produto;
}
}
}
}
Veja
o método Encontra(). Ele recebe um CarrinhoDeCompras e percorre a
lista de produtos, comparando sempre o produto corrente com o menor e maior de
6
Casa do Código
Capítulo 2. Testes de Unidade
todos. Ao final, temos nas propriedades Maior e Menor os produtos desejados. A
figura abaixo mostra como o algoritmo funciona:
Para exemplificar o uso dessa classe, veja o código abaixo:
public class TestaMaiorEMenor
{
static void main(String[] args)
{
CarrinhoDeCompras carrinho = new CarrinhoDeCompras();
carrinho.Adiciona(new Produto("Liquidificador", 250.0));