O documento discute a importância de se escrever testes unitários para o desenvolvimento de software, comparando o desenvolvimento guiado a debug (DDD) com o desenvolvimento guiado a testes (TDD). Apesar de inicialmente difícil, escrever código testável traz benefícios como código mais robusto e menos bugs, e o autor fornece exemplos práticos de como começar a escrever testes unitários em C#.

1. Testes Unitários
Começando a escrever testes no seu dia-a-dia
Alex Tercete
alex.matos@chemtech.com.br
27 de abril de 2011

2. Espera aí...
Você já falou disso!

3. 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 (*)

4. 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? DEBUG
Não
Comemorar!
Sim

5. Debug-Driven
Development
(DDD)

6. 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

7. Test-Driven
Development
(TDD)

8. Mas isso não é
trabalho dobrado?

9. 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

10. Os benefícios do TDD
• Código desacoplado e com bom design
• Robustez
• Evita problemas de regressão
• Aumenta a confiança do desenvolvedor

11. Por que ainda não
estou fazendo isso?

12. 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);
}

13. O desafio é escrever
código testável

14. 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.

15. 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

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

17. Um exemplo
• Ideias?!

18. Organizando seu Projeto
• Separar o projeto/pacote contendo os testes
– <NomeDoProjeto>
– <NomeDoProjeto>.Testes
• Acessando métodos internos
– Properties/AssemblyInfo.cs
[assembly: InternalsVisibleTo("<NomeDoProjeto>.Testes")]

19. 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

20. Depurando os testes unitários
• GUI Runner
• Debug > Attach to Process...
• Rodar testes

21. Como começar?

22. 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

23. Vivemos na era da informação

24. 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/

25. Dúvidas?