O documento discute boas práticas de testes de software, como escrever testes melhores, evitar más práticas e utilizar padrões de teste. Aborda tópicos como a pirâmide de testes, escrever testes unitários focados em comportamentos e não em classes, utilizar dublês de teste e evitar excesso de mocks. Também discute como organizar os testes e cuidados para manter a estabilidade e legibilidade dos casos de teste.

1. BOAS
PRÁTICAS
DE
TESTES,
BAD
SMELL
E
OUTROS
MACETES
Por Ismael Soares

2. POR QUE VOCÊ
TESTA SEU CÓDIGO?

3. ME AJUDA NO DESIGN
GARANTIR REGRAS DE NEGÓCIO
ENTENDER O NEGÓCIO
AJUDA RESOLVER PROBLEMAS
COMPLEXOS
ETC.

4. OK,
MAS
COMO
O
TESTE
TE
AJUDA
COM
ESTAS
COISAS?

5. FEEDBACK!

6. VOCÊ
OS
ESCUTA?

7. Mike
Cohn
(Succeeding
with
Agile)
PIRÂMIDE
DE
TESTES

8. UNIDADE

9. MAS
O
QUE
É
UMA
UNIDADE?

10. UMA UNIDADE DE NEGÓCIO É UM
COMPORTAMENTO DO SEU CÓDIGO!
______________________________
Martin Fowler

11. NÃO É UMA CLASSE OU UM MÉTODO
Thought
Works

12. VOCÊ DEVE SE PREOCUPAR MAIS
COM O QUE
DO QUE COM COMO

13. ESCREVENDO
TESTES
MELHORES

14. Referência:
https://info.thoughtworks.com/praticas-e-tendencias-em-teste-ebook.html

15. #
TRATE
O
CÓDIGO
DE
TESTES
COMO
DE
PRODUÇÃO
https://8thlight.com/blog/uncle-bob/2013/09/23/Test-first.html
TEST FIRST

16. TESTS ARE SPECS

17. ROTTEN TESTS

18. SIMPLE DESIGN

19. #
UTILIZE
UM
PADRÃO
DE
TESTES

20. OS 3 AS - ARRANGE, ACT E ASSERT
Organizar:
Configure
suas
informações
e
qualquer
outro
dado
necessário
ao
teste
Agir:
Execute
a
ação
que
vai
validar
Verificar:
Veja
o
que
era
esperado
realmente
aconteceu

21. PADRÃO BDD

22. #
NÃO
CONVIVA
COM
TESTES
INSTÁVEIS

23. ERADICATING NON-
DETERMINISM IN TESTS
http://martinfowler.com/articles/nonDeterminism.html
Não
passa
segurança
Precisa
de
interpretação
Vira
paisagem
com
tempo

24. #
UTILIZE
DUBLES
DE
TESTES
http://rkmael.com/2014/11/13/dubles_testes/

25. http://rkmael.com/2014/11/17/comparando-dubles-testes/
COMPARANDO DUBLES

26. #
CUIDADO
COM
EXCESSO
DE
MOCKS

27. SEM PERCEBER VOCÊ PODE
ESTAR MOCKANDO UM
COMPORTAMENTO

28. QUANDO USAR MOCKS?
Quando
o
comportamento
não
é
responsabilidade
da
unidade
testada.
Exemplo:
um
Service
chamando
outro,
um
Service
chamando
um
DAO,
um
Controller
chamando
um
Service,
etc.

29. E UMA REGRA CHAMADA
DENTRO DE UM MODEL/
ENTITY, DEVO MOCKAR?

30. MÁS
PRÁTICAS

31. #
TUDO
NO
MÉTODO
BEFORE

32. @Before
-­‐
uma
vez
antes
de
cada
teste
@BeforeClass
-­‐
uma
vez
apenas
antes
de
todos
os
testes
@After
-­‐
uma
vez
depois
de
cada
teste
@AfterClass
-­‐
uma
vez
apenas
depois
de
todos
os
testes

33. #NÃO
EVIDENCIAR
O
CENÁRIO

34. ERRADO
CORRETO

37. #CENARIOS
GIGANTES

40. SE O CENÁRIO ESTA MUITO
GRANDE É PORQUE SEU
CÓDIGO ESTÁ MUITO
ACOPLADO

41. #CENARIOS
IMPRONUNCIAVEIS

42. deveRetornarMensagemDeValidacaoDaDataDeEmissaoEBloqu
earANotaFiscalQuandoOUsuarioNaoTiverPermissoesEADataDe
EmissaoUltrapassarADataParametrizadaEOStatusDeRecebimen
toForDiferenteDeReceberComDataAcimaDoParametrizado

43. SE VOCÊ NÃO CONSEGUE
EXPRESSAR DE FORMA
SIMPLES UM CENARIO, É
SINAL DE QUE ESTA MUITO
COMPLEXO

44. #TESTE
DE
EXCEPTION
SE
VALIDAR
A
MENSAGEM

45. ERRADO

46. CORRETO

47. #NÃO
VALIDAR
A
ORDEM
DAS
INTERAÇÕES

48. ERRADO

49. CORRETO

50. #ALTERAR
O
CÓDIGO
DE
PRODUÇÃO
APENAS
POR
CAUSA
DOS
TESTES

51. DEIXAR O MÉTODO DEFAULT
PRA TESTA-LO
CRIAR SETTER PARA FAZER
INJEÇÃO DE DEPENDÊNCIA
CRIAR MÉTODO PARA ALTERAR O
ESTADO DO CÓDIGO DURANTE O
TESTE

52. Obrigado
@rkmael
rkmael@hotmail.com
rkmael.com