O documento discute a importância dos testes de software, destacando a necessidade de garantir que o código funcione como esperado e evitando a introdução de novos bugs. Ele apresenta os testes unitários, seus benefícios e a prática do Test-Driven Development (TDD), além de explicar a diferença entre 'stubs' e 'mocks' no contexto de testes. A documentação enfatiza que, embora os testes possam consumir tempo, são essenciais para a qualidade e a manutenção do software.

1. Testes e Mock´s

2. Razões e problemas
 Difícil manter
 Difícil evoluir
 Bugs persistentes
 Correção gera outros bugs
 Medo de mexer no código
 Perda de tempo

3. O que são testes
 Forma de garantir que o software funciona
◦ Atende aos propósitos de negócio
◦ Funciona como esperado
 Maneira verificável de garantir que o
software atende „as necessidades de
negócio e que funciona como esperado

4. Testers
 São importantes
 Executar a aplicação demora
 Feedback demora
 Bom para encontrar bugs
 Código construído sobre bug gera mais
bugs

5. Por que não testar ?
 Demora..
 Eu sou senior..
 Estamos sem tempo ..

6. Por que não testar?
 Acredite: você não é o bom o bastante!!
 Testar pode consumir tempo, mas é
necessário.
 Deixar de testar não te faz mais rápido,
dá apenas uma falsa sensação de
velocidade.

7. Produtividade ao longo do tempo

8. Uncle Bob (Robert C. Martin)
“Desenvolvedores que não
testa é como um cirurgião que
não lava as mãos”

9. Uncle Bob (Robert C. Martin)

10. O que é um teste unitário?
 Pedaço de código que executa outro
pedaço de código.
 Verifica se tudo esta correto
 Teste uma coisa por vez
 Não toque em nada externo (DB,file, etc)
 É um trabalho do desenvolvedor
 Escreva e vá refatorando código

11. Benefícios dos testes unitários
 Pequeno, justo, dissociado
 Executam de forma automatizada
 São repetíveis
 Qualquer um pode executar
 Provém FeedBack quase instantâneo
 Refatoração segura
 Documenta os requisitos
 Permite a integração contuínua

12. Benefícios dos testes unitários
 O valor dos teste aumenta com o tempo
 Auxiliam o design da funcionalidade
◦ Escrever teste tem de ser fácil
◦ Esta difícil ? Esta errado!! Refatore
 Ajudam a realizar alterações
 Ajudam com regressões
◦ Algo que funcionava e não funciona mais

13. Units Test
 E as desvantagens ....

14. Quando escrever os teste
Antes (TDD, BFF) Depois/Durante code
 Foco no requerimento
 Pensa sobre como o
código será
consumido
 Para de codificar
quando requerimento
é encontrado
 Difícil inicialmente
 Foco no código
 Pensa no algoritmo
 Mais refatoração é
necessária
 Fácil de iniciar

15. Quando escrever os teste
Antes (TDD, BFF) Depois/Durante code
 Foco no requerimento
 Pensa sobre como o
código será
consumido
 Para de codificar
quando requerimento
é encontrado
 Difícil inicialmente
 Foco no código
 Pensa no algorítimo
 Mais refatoração é
necessária
 Fácil de iniciar

16. Anatomia AAA
 Teste são curtos seguem o padrão AAA
 Arrange
◦ Setup de código e pré-requisitos, prepara o
ambiente para o teste
◦ Configura as variáveis, objetos, monta relações
◦ Em algumas situações o Arrange pode ser
reaproveitado
◦ Exercita o método em teste
 [Setup]
 [TestInitialise]
 [FixtureSetup]

17. Arrange Extenso

18. Anatomia AAA
 ACT
◦ É execução do SUT
◦ É a chamada para o método que esta sendo
testado
◦ É a execução da operação a ser testada
◦ Um teste deve atuar independente dos outros
◦ Um Act com muitos métodos é sinal de
problema

19. Anatomia AAA
 Assert
◦ É a verificação do resultado
◦ Neste ponto faz-se a análise do resultado do
ACT como era esperado
◦ Um teste no geral tem apenas Um Assert
◦ Mais de um Assert no teste mascara erros

20.  Frameworks de Teste
◦ NUNIT
◦ Portado no junit
◦ 100% escrito em C#
◦ Um dos frameworks mais usados
◦ Interface Fluentes
◦ Asseções mais legíveis
◦ Mais opções de Asserções

21. Coloque para fora as dependencias
 Envolva a dependência com uma
Interface
 Crie um campo privado tipo de interface
 Adicione a interface com argumento no
construtor
 Assimile o campo privado ao argumento
no construtor
 Use um novo campo privado no código

22. TDD
 Basicamente deve se seguir o mantra:
◦ RED, GREEN , Refactor
 Escreva um teste que falhe
 Faça o teste passar
 Refatore/melhore o código

23. TDD
 Escrever os teste antes do código de
produção
 Escrever código que o teste pediu
 Resultados
◦ Teste
◦ Melhor design
 Menos acoplamento
 Classes e métodos coesos
 Clareza no código
 Por que teste ante?
◦ O teste é o primeiro cliente do seu código
◦ Faça como você gostaria que fosse

24. Exemplo de código
ERP

25. O que é Mocking?
 Cria objetos falsos para você
 Coloque e inspecione os valores no objeto
falso
 Inspecione os métodos chamados e
argumentos no objeto falso

26. Stub vs Mock
 Server para gerenciamos dependências
nos testes
 Ambos são objetos fake, “imitam” objetos
reais
 São muito parecidos mas têm propósitos
diferentes

27. Stubs
 Substitui de forma controlável uma
dependências externas
 Mantém o teste em nossas mãos
◦ Repetível
◦ Rápido
◦ Isolado
 Um stub não fará o teste falhar
 Asserts não são feitos contra os Stubs
 Fornece algum estado para o SUT

28. Mocks
 É um objeto que reage às interações com
o SUT
 Tem poder para falhar o teste
 Assert é realizado contra o mock
 Um mock por teste
◦ SRP até no teste!!!!

29. Stub vs Mock
STUB MOCK
 GET/SET proriedades
 Set metodos e
retorna valores
 Testa o estado!
 Checa a chamada de
métodos
 Checa os argumentos
usados
 Testa Interações!

30. Stubs e Mocks
 Indispensáveis
 Sem eles testar é doloroso e custoso
 Criá-los na mão é doloroso e custoso
 Gera muito retrabalho
 Gasta-se muito tempo
 Testar fica chato

31. Framework de Mock
 Frameworks de isolamento
 Criam Mocks e Stubs de forma simples
 Não há retrabalho
 Lidam com vários tipos de configuração
sem causar odores
 Frameworks
◦ Rhino.Mocks
◦ Typemock Isolator
◦ Moq