October 13, 2016 Web.br hugeinc.com

Transcrição

1 October 13, 2016 Web.br hugeinc.com

2 13 de outubro, 2016 Desenvolvendo aplicações de qualidade com TDD Huge

3 Isabella Silveira Web Huge. Front-End, Back-End, Agile e Integração Contínua.

4

5

6

7

8

9

10

11

12 Agenda. 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. 8. Conclusão.

13 Introdução.

14 Hoje em dia, a qualidade é um diferencial em tudo que consumimos.

15

16 E podemos dizer que o mundo moderno funciona a base de código.

17

18

19

20

21 Qualidade de software é uma preocupação crescente.

22 TDD é uma ótima ferramenta para nos ajudar a alcançar este objetivo.

23 O que é TDD?

24 Vamos falar de coisa boa.

25 Testes de Software.

26 O que é TDD? Tipos de teste de software.

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

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

29 Garantem o funcionamento de cada parte individual do sistema.

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

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

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

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

34 Vista Integração Unitários

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

36 O que é TDD? As três leis do TDD.

37 As trêsleis do TDD: Você deve escrever um teste que falhe antes de escrever qualquer código de produção.

38

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

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

41 As três leis do TDD: Você não deve escrever um teste que contenha mais do que o necessário para simular o comportamento da função.

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

43 As três leis do TDD: Você não deve escrever mais código de produção do que o suficiente para fazer o teste passar.

44 A failing test should read like a highquality bug report. Eric Elliott

45 Mas como eu sei o que testar?

46 Divida a sua user story em features, e as features em unidades atômicas.

47 Eu, enquanto usuário, gostaria de ser redirecionado para a home depois de logar no sistema.

48 Definição de feature: Form de login.

49 Próximo passo: Definir as funcionalidades e o comportamento esperado dessa feature.

50

51

52 Por que usar TDD?

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

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

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

56

57 TDD reduz a complexidade do código.

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

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

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

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

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

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

64

65 Testes previnem código quebrado.

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

67 Testes acabam com o medo de refactorings.

68

69 TDD facilita a identificação de bugs de regressão.

70 TDD estimula designs modulares.

71 Show me the code.

72 Show me the code Quatro perguntas primordiais.

73 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?

74 Exemplo prático: logintosystem()

75 Red.

76

77

78

79

80 Green.

81

82

83 Refactor.

84

85

86

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

88

89

90

91

92 Boas práticas.

93 Cada teste deve ser independente.

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

95 Mocke os estados e recursos externos.

96 Use nomes e descrições consistentes.

97 Teste um comportamento de cada vez.

98 Ferramentas.

99 Ferramentas Frameworks de teste.

100

101 Ferramentas Test runners.

102

103 Próximos Passos.

104 Code Coverage.

105 Karma Coverage.

106 Integração Contínua.

107

108 Conclusão.

109 Qualidade agrega valor à sua aplicação.

110 TDD não é a única forma de garantir a qualidade do software, apesar de ser um bom aliado.

111 Sempre prezar por um código modularizado e testável.

112 E o mais importante de tudo:

113 Qualidade de software não é opcional.

114 Perguntas?

115 Get in /in/isabellasilveira /bella-silveira

116