Testes Unitários: Começando a escrever testes no seu dia-a-dia

Testes Unitários

Começando a escrever testes no seu dia-a-dia

Alex Tercetealex.matos@chemtech.com.br

27 de abril de 2011

Espera aí...

Você já falou disso!

O que mudou?

• Chemtech Coding Dojo• Uso na prática– SIMONS, ONS (Importação Automática)

– Viva 2.0, Coca-Cola (Aplicativo do Twitter)

– GERCAD, ONS (*)

Escrever código

Como desenvolvemos atualmente

Camada de apresentação

(Web, UI)

Camada de Serviço

Camada de Lógica

Camada de Acesso a Dados

“Clicar no botão”

Funcionou? DEBUGNão

Comemorar!

Sim

Debug-Driven Development

(DDD)

Uma nova forma de pensar

Camada X

Escrever teste

Implementar funcionalidade

Terminou?Não

Fim

Sim

Camada Y

Escrever teste

Implementar funcionalidade

Terminou?Não

Fim

Sim

Camada Z

Escrever teste

Implementar funcionalidade

Terminou?Não

Fim

Sim

Test-Driven Development

(TDD)

Mas isso não é trabalho dobrado?

Uma análise do tempo gasto no DDD

• “Clicar no botão”– Levantar servidor de desenvolvimento– Compilar páginas .aspx, .jsf, etc.– Acessar manualmente a página e realizar os

passos para execução da funcionalidade– Executar query no banco

• Debug– Adicionar/remover breakpoints e watches– Depurar o código linha a linha

• Paciência• Atenção

Os benefícios do TDD

• Código desacoplado e com bom design• Robustez• Evita problemas de regressão• Aumenta a confiança do desenvolvedor

Por que ainda não estou fazendo isso?

Escrever testes unitários é fácil

[Fact]public void TesteDePotenciacao(){ // Arrange var calculadora = new Calculadora();

// Act var resultado = calculadora.Eleva(3, 4); // Assert Assert.Equal(81, resultado);}

O desafio é escrever código testável

Escrever código testável é difícil

• Quebra de hábitos antigos• Aprender nova forma de pensar/trabalhar• Algumas tecnologias são naturalmente mais

difíceis de testar– Interface Gráfica– Stored Procedures– Componentes de terceiros– etc.

A mudança não é instantânea

• No início você vai escrever código “mais ou menos” testável

• Você vai errar• Você vai desejar ter feito as coisas de forma

diferente• Você vai evoluir• Você não vai mais conseguir desenvolver de

outra maneira

Tá, mas eu quero ver um exemplo disso na prática!

Um exemplo

• Ideias?!

Organizando seu Projeto

• Separar o projeto/pacote contendo os testes– <NomeDoProjeto>– <NomeDoProjeto>.Testes

• Acessando métodos internos– Properties/AssemblyInfo.cs

[assembly: InternalsVisibleTo("<NomeDoProjeto>.Testes")]

Test Doubles

• Dummy– Nunca é usado

• Fake– Implementação do objeto real, mas com “atalhos”

• Stubs– Não fazem nada

• Spies– Stubs que registram informações sobre as chamadas

• Mocks– Imitações do objeto real, para chamadas específicas

Depurando os testes unitários

• GUI Runner• Debug > Attach to Process...• Rodar testes

Como começar?

O que você pode fazer

• Just Do It!• Estime o tempo das suas tarefas levando em

conta os testes unitários• Comece testando o que for mais fácil• Dê prioridade à lógica principal da aplicação• Mostre aos seus colegas os benefícios que os

testes unitários podem trazer• Pesquise, estude e peça ajuda

Vivemos na era da informação

Referências

• http://elegantcode.com/2008/05/20/get-started-writing-testable-code/

• http://www.martinfowler.com/bliki/TestDouble.html• http://

googletesting.blogspot.com/2008/11/clean-code-talks-unit-testing.html

• http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf

• http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-decided-to.html

• http://hashbucket.wordpress.com/2009/01/12/unit-testing-internal-methods/

Dúvidas?