Testes em JS Como Você Nunca Viu Antes

My slides for the presentation in JSDay Recife 2017, which happened at Nov. 26th, 2016.

Transcript

1. Testes em JavaScript Como você nunca viu antes @lfernandescosta @lucasfcosta lucasfcosta.com
2. ‣ Sistemas de Informação @UFSC ‣ FullStack Developer @MyTapp ‣ ChaiJS Core Maintainer ‣ Apaixonado por Open Source Quem sou eu?
3. ‣ Sistemas de Informação @UFSC ‣ FullStack Developer @MyTapp ‣ ChaiJS Core Maintainer ‣ Apaixonado por Open Source Quem sou eu? Internacionalmente conhecido por causar prejuízo em buffet livre de sushi
4. Quem sou eu? @lfernandescosta @lucasfcosta lucasfcosta.com
5. Por que testar?
6. Qualidade do código
7. Ok, todo mundo sabe disso Qualidade do código
8. Agilidade Melhores estimativas Mais feedback Mais rápido
9. < Redução de custos
10. QA + Trabalho Proativo - Trabalho Reativo
11. Validação ‣ Feedback rápido ‣ Prova que o código está correto OS DOIS LADOS DO TDD TDD
12. Validação Unde omnis iste. ‣ Feedback rápido ‣ Prova que o código está correto OS DOIS LADOS DO TDD Especificação TDD ‣ Demonstra o que aquela peça deve fazer ‣ Demonstra os resultados esperados
13. Validação Unde omnis iste. ‣ Feedback rápido ‣ Prova que o código está correto OS DOIS LADOS DO TDD Especificação TDD ‣ Demonstra o que aquela peça deve fazer ‣ Demonstra os resultados esperados O teste serve como spec
14. Requisitos mais claros Primeiro você pensa
15. Requisitos mais claros Primeiro você pensa Depois você coda
16. Test Driven Design
17. Program to an interface, not an implementation
18. Program to an interface, not an implementation Menos acoplamento
19. "TDD Should be Fun" - James Sinclair
20. Feedback Loop Metas de Longo Prazo Recompensas Rápidas VS.
21. Feedback Loop Metas de Longo Prazo Recompensas Rápidas VS. ‣ Feedback positivo constante e rápido
22. Feedback Loop Metas de Longo Prazo Recompensas Rápidas VS. ‣ Feedback positivo constante e rápido ‣ Reduz o medo, prova que você está no caminho certo
23. Feedback Loop Metas de Longo Prazo Recompensas Rápidas VS. ‣ Feedback positivo constante e rápido ‣ Você sabe que está no caminho certo DIVERSÃO
24. Bons motivos para testar:
25. Bons motivos para testar: 1 Agilidade
26. Bons motivos para testar: 1 Agilidade 2 Redução de custos
27. Bons motivos para testar: 1 Agilidade 2 3 Redução de custos QA Proativo
28. Bons motivos para testar: 1 Agilidade 2 4 3 Redução de custos Especificação QA Proativo
29. Bons motivos para testar: 1 Agilidade 2 4 5 3 Redução de custos Especificação QA Proativo Test Driven Design
30. Bons motivos para testar: 1 Agilidade 2 4 5 6 3 Redução de custos Especificação QA Proativo Diversão Test Driven Design
31. Como escrever bons testes?
32. Só automatizar não é o suficiente
33. Automated crap is still crap
34. Você não pode provar que seu software funciona
35. Você não pode provar que seu software funciona Você só pode provar que ele não funciona
36. Desenvolvimento em pequenos passos
37. Desenvolvimento em pequenos passos Mais segurança
38. Passos do tamanho da sua segurança
39. Passos do tamanho da sua segurança
40. "Qual tamanho devem ter meus testes?"
41. "Qual tamanho devem ter meus testes?"
42. "Qual tamanho devem ter meus testes?" O necessário
43. "Qual tamanho devem ter meus testes?" O necessário Somente o necessário
44. "Qual tamanho devem ter meus testes?" O necessário Somente o necessário O extraordinário é demais
45. Isolamento Teste unitário testa apenas uma unidade (função)
46. Isolamento Teste unitário testa apenas uma unidade (função) Quando algo falhar, sabemos pontualmente o que falhou
47. Isolamento
48. Independência Um teste depende apenas de uma “peça”
49. Independência Um teste depende apenas de uma “peça” Um defeito causa falha em um teste
50. Independência Stubs
51. Independência
52. Foco Um teste tem apenas um objetivo
53. Foco Um teste tem apenas um objetivo Faça o mínimo de asserções por teste
54. Foco Evite testes "frouxos"
55. Foco Evite testes "frouxos"
56. Foco Evite testes "frouxos" Quantos testes passam nisso?
57. Foco
58. Desacoplamento O teste não depende da implementação
59. Desacoplamento O teste não depende da implementação Program to an interface, not an implementation
60. Desacoplamento Você paga por testes em manutenção
61. Para fazer bons testes:
62. Para fazer bons testes: 1 Isolamento
63. Para fazer bons testes: 1 Isolamento 2 Independência
64. Para fazer bons testes: 1 Isolamento 2 3 Independência Foco
65. Para fazer bons testes: 1 Isolamento 2 3 4 Independência Foco Desacoplamento
66. Estou no caminho certo?
67. Testes que falham são testes que produzem informações
68. Testes que falham são testes que produzem informações Se arrisque
69. Code coverage é bom
70. Code coverage é bom Mas não é tudo
71. 100% Code Coverage function incrementaIndice(arr, i) ➡ Soma 1 ao valor de índices já existentes ➡ Se o valor naquele índice é indefinido ele passa a ser 1
72. 100% Code Coverage
73. 100% Code Coverage Asserções
74. 100% Code Coverage Asserções Possibilidades de entrada
75. Medindo Coverage
76. Medindo Coverage
77. Cross-platform
78. Cross-platform Diferentes implementações
79. Cross-platform Diferentes implementações Diferentes features suportadas
80. Cross-platform Tenha fallbacks
81. O ecossistema parece grande…
82. O ecossistema parece grande…
83. O ecossistema parece grande… Mas é simples
84. The UNIX Philosophy
85. Mais possibilidades The UNIX Philosophy
86. Mais possibilidades Aprendizado gradual The UNIX Philosophy
87. Recapitulando:
88. Recapitulando: 1 Mocha
89. Recapitulando: 1 2 Mocha Chai
90. Recapitulando: 1 2 3 Mocha Chai Sinon
91. Recapitulando: 1 2 4 3 Mocha Chai Sinon Istanbul
92. Recapitulando: 1 2 4 5 3 Mocha Chai Sinon Istanbul Karma
93. Valeu, Recife!
94. Valeu, Recife! Free software is great software