Experiência de quase 2 anos tentando inserir e manter a cultura de testes automatizados numa empresa. Desafios e as barreiras enfrentadas ao adotar a cultura de testes automatizados nesta empresa, onde acertamos e onde erramos, como a equipe (e isso inclui os gerentes) responderam a mudança e como isso impactou nos sprints e entrega de software.

1. Greenbar
Testes automatizados na sua empresa
Rafael Ponte

4. Quem escreve testes?

5. http://blog.fragmental.com.br/2007/10/31/programadores-profissionais-
escrevem-testes-ponto-final/

6. Você é um programador
profissional?
#provocacaogratuita

7. Por que testar?
Para verificar se o sistema se comporta como
deveria.

8. Como testar?
Testes manuais.
Testes automatizados.

9. Testes automatizados.
Trazem mais confiança.
Identificam regressões de código.
Permitem refatorar com segurança.

10. Tudo começou com uma
consultoria.

11. Erros e
Desafios Impacto
Acertos

12. Erros e
Desafios Impacto
Acertos

13. Convencer a gerência.
Seria um investimento de médio-longo prazo.

14. Projeto já em andamento.
Dificuldade para escrever testes.

15. Infra?
Não tínhamos nada pronto!

16. Colaboração da equipe.
Equipe de bons desenvolvedores, mas sem
experiência com testes.

17. Zona de Conforto

18. Devs. simpatizantes.
Teste de integração é teste de “maxu”!

19. Erros e
Desafios Impacto
Acertos

20. Por onde começar?
Baby steps.

21. Testes de Unidade
Melhorando o design das classes aos poucos.

22. Eclipse já vem com jUnit
Mãos à obra!

23. SEM mocks.
Modelo, classes utilitárias e de
responsabilidade bem definidas.

24. COM mocks.
Utilizá-los não é tão simples quanto parece.

25. JMock VS Mockito

26. Testes de Integração
Teste de “maxu” vai no banco.

27. Spring Testing + DBUnit

28. Sujar ou não sujar o banco,
eis a questão.

29. 100% de cobertura.
Esta não deveria ser sua meta.

30. No início era a melhor
meta/métrica que
tínhamos.

31. Getters&Setters
Um testezinho a mais não faz mal, né.

32. Testes mal escritos.
Você vai escrevê-los, pode ter certeza disso.

33. Testes frágeis, pouco
legíveis e com assertivas
ruins.

34. Refatoração Contínua
neles!

35. Ainda assolados pela
pouca legibilidade.

37. Há 4-5 anos o
mercado gritava:
“Antes testes
mal escritos do
que nenhum
teste.”

39. Buscando ajuda no BDD.
Testes são especificações executáveis.

40. • Nome de métodos mais expressivos
• Template Given-When-Then
• Nos forçou a pensar mais no
negócio e no que realmente
devemos testar
• Maior interação com o cliente

42. TDD.
Somente em regras de negócio complexas.

43. OOP e SOLID Principles
Sem estes conhecimentos não é tão simples ter
um bom design.

44. Automatizando.
Automatize o máximo que você puder.

45. Ant + Hudson
Simples e prático.

46. $ git pull --rebase; ant

47. Excesso de informação
Relatório de testes, Find Bugs, PMD, Checkstyle e
Coverage

48. Code Review.
Relatório de testes e Coverage são suficientes.

49. Build do Hudson
quebrando.

50. Nosso mantra:
“Hudson quebrou? Pára
tudo e conserta.”

51. Testes de Aceitação.
Tudo ia bem, até o dia em que o número de
testes cresceu demais.

52. Selenium/WebDriver
Precisávamos de alguém com experiência.

53. @handersonbf
Um EMO num corpo de um OGRO.
Selenium/WebDriver
Precisávamos de alguém com experiência.

54. Testando cenários
importantes.
Começamos do jeito certo.

55. Test Automation Pyramid
Aceitação - 10%
Integração - 40%
Unidade - 50%

56. More, more...
Testes com granularidade fina demais.

57. Test Automation Pyramid
Square
Aceitação - 30%
Integração - 30%
Unidade - 40%

58. Mantê-los se tornou caro.
Frágeis, feedback demorado, falsos negativos e
difícil rastrear erros.

59. Nos tornamos mais
criteriosos.

60. Design das telas mudava
constantemente.
E nem sempre o designer rodava os testes.

61. Designer disciplinado.
E testes de aceitação fora do build principal.

62. Zona de Conforto DE NOVO!

63. Testes difíceis de rodar.
Executar o build ou levantar o Tomcat era chato.

64. Facilite a vida da equipe.
Jetty embarcado.

65. Cucumber.
Cliente sem interesse de ler e muito menos
escrever as features.

66. Erros e
Desafios Impacto
Acertos

67. Qualidade no software.
Menor incidência de bugs e correções rápidas.

68. De 100% para 25%.
Melhoramos nossas estimativas.

69. Fim do Sprint.
Menor número de features entregues.

70. PRODUTIVIDADE.
Baixa no início. Melhora durante os Sprints.

71. Gerência.
Satisfeita com a produtividade de alguns
projetos, decepcionada com outros.

72. Equipe mais madura.
Perceberam a importância real dos testes.

73. CONCLUSÃO
Depois de quase 2 anos escrevendo testes.

74. Você só percebe os benefícios dos testes entre
6 meses e 1 ano

75. Nem tudo são flores.
Mas a gerência continua acreditando piamente nos
testes automatizados.

76. Enfim,
VALE A
PENA.

77. OBRIGADO!
Rafael Ponte
rponte@triadworks.com.br