A cada dia que passa, as aplicações web e mobile tem se tornado cada vez maiores e mais complexas, mas como garantir que tudo esteja funcionando conforme o esperado durante todo o tempo? Nesta palestra entenderemos como a prática do Desenvolvimento Orientado a Testes é essencial para garantir a qualidade e o bom funcionamento de sistemas, mostrando diferentes tipos de testes que atuam em cada camada da aplicação e os melhores frameworks para por tudo isso em prática.

1. 19 de Dezembro, 2015
R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com

2. All You Need
Is TDD
Huge
19 de dezembro, 2015

3. 1. Introdução 2. O que é TDD?
3. Por que usar TDD? 4. Show me the code
5. Boas práticas 6. Ferramentas
7. Próximos passos
Agenda.

4. Introdução.

5. Front-End Developer @ Huge.
Front-End, Back-End, DB, Agile
e Integração Contínua.
/bella-silveira
Isabella Silveira
/in/isabellasilveira
@silveira_bells
isilveira@hugeinc.com

6. O que é TDD?

7. Tipos de teste de software.
OqueéTDD?

8. Tipos de teste de software.
1.Testes unitários.
2.Testes de integração.
3.Testes de aceitação.

9. Tipos de testes de software.
1. Testes unitários.
2. Testes de integração.
3. Testes de aceitação.

10. Garantem o funcionamento de cada
parte individual do sistema.

11. Tipos de testes de software.
1. Testes unitários.
2. Testes de integração.
3. Testes de aceitação.

12. Asseguram que duas ou mais
unidades funcionam corretamente
quando trabalhando juntas.

13. Tipos de teste de software.
1.Testes unitários.
2.Testes de integração.
3.Testes de aceitação.

14. Testes na vista,simulam o
comportamento do usuário.

15. Integração
Unitários
Vista

16. “ Tá,então o que é TDD?”

18. Metodologia de desenvolvimento de
software onde os testes são escritos
antes das funcionalidades em si.
O que é TDD?

19. As três leis do TDD.
OqueéTDD?

20. Você deve escrever um
teste que falhe antes de escrever
qualquer código de produção.
AstrêsleisdoTDD:

22. "Getting software to work is only half of
the job."
Robert C. Martin (Uncle Bob)

23. Primeiro fazer o código funcionar,
depois melhorar a estrutura.

24. Você não deve escrever um
teste que contenha mais do que
o necessário para fazê-lo falhar.
AstrêsleisdoTDD:

25. Keep it simple: faça apenas o
necessário no escopo da função.

26. Você não deve escrever mais
código de produção do que o
suficiente para fazer o teste passar.
AstrêsleisdoTDD:

27. “A failing test should read like a high-
quality bug report.“
Eric Elliott

29. Por que
usar TDD?

30. Por que usar TDD?
1.Auxilia no design da API.
2.Testes = Documentação.
3. Código de qualidade.
4.Viabiliza IC.

31. Por que usar TDD?
1. Auxilia no design da API.
2. Testes = Documentação.
3. Código de qualidade.
4.Viabiliza IC.

32. TDD te dá uma perspectiva mais
clara do que realmente é necessário.

34. TDD reduz a complexidade
do código.

35. Por que usar TDD?
1.Auxilia no design da API.
2.Testes = Documentação.
3. Código de qualidade.
4.Viabiliza IC.

36. Cada teste documenta com exatidão
o comportamento de cada função.

37. Por que usar TDD?
1.Auxilia no design da API.
2.Testes = Documentação.
3. Código de qualidade.
4.Viabiliza IC.

38. Cada linha de código testado é uma
linha de código confiável.

40. Por que usar TDD?
1.Auxilia no design da API.
2.Testes = Documentação.
3. Código de qualidade.
4.Viabiliza IC.

41. A integração contínua fornece o
panorama geral da aplicação.

43. Testes previnem código quebrado.

45. Testes mapeiam cada parte do
comportamento da sua aplicação.

47. Testes acabam com o medo
de refactorings.

49. TDD reduz a quantidade de bugs.

50. TDD facilita testes de regressão.

51. TDD estimula designs modulares.

52. Show me
the code.

53. Quatro perguntas primordiais.
Show me the code.

54. Quatro perguntas primordiais.
1. O que eu estou testando?
2. Quais os parâmetros?
3. Qual a saída obtida?
4. Qual a saída esperada?

55. Exemplo prático: logIntoSystem()

56. Red

61. Green

64. Refactor

67. Testar o comportamento em caso de
falha também é importante.

72. Boas práticas.

73. Cada teste deve ser independente.

74. Não faça asserções desnecessárias.

75. Mocke os estados e
recursos externos.

76. Use nomes e
descrições consistentes.

77. Teste um comportamento
de cada vez.

78. Ferramentas.

79. Frameworks de teste.
Ferramentas.

81. Test runners.
Ferramentas.

83. Próximos Passos.

84. Integração Contínua.

86. Perguntas?

87. 19 de Dezembro, 2015
R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com