O documento discute a importância de se escrever testes de software, especialmente testes unitários, e fornece diretrizes sobre como estruturar diferentes tipos de testes. É recomendado testar unidades menores de código através de testes unitários para fornecer feedback rápido, e também realizar testes de integração e aceitação, apesar de serem mais demorados. Um sistema de integração contínua ajuda a automatizar e agilizar o processo de teste.

1. Testes
pra que?
@rodrigodealer

2. Noite de sono :-)

3. Cliente satisfeito :D

4. Todos felizes :-D

5. Exemplo :-)

6. (Ruby)

7. Meio grande, né?
E esse?

8. “Ruby é feito para ser bonito. Se está feio, está errado.”
Matz

9. Aquele if, else foi
embora o/
“Extract method” - Faz bem

10. Variável desnecessária
Código repetido
Backspace/Del salva vidas :-)

11. Ok, fiz esse refactoring, que garantia eu
tenho que vai funcionar?

12. Com testes!

13. Testes unitários

14. Certa vez um sábio disse:
A test is not a unit test if:
* it talks to the database
* it communicates across the network
* it touches the file system
* it can’t run at the same time as any of your other unit tests
* you have to do special things to your environment (such as editing config files) to run it
Tests that do these things aren’t bad. Often they are worth writing, and they can be written in a unit
test harness. However, it is important to keep them separate from true unit tests so that we can run
the unit tests quickly whenever we make changes.
--
Ou um chapa disse em português:
Um teste não é um teste unitário se:
- Comunica com o banco de dados
- Comunica pela rede
- “Toca” no sistema de arquivos
- Se não pode ser rodado ao mesmo tempo de outros testes unitários
- Se você tem que configurar determinadas coisas como arquivos de configuração

15. Testar unitariamente é

16. Testar a menor porção de código

17. Devem rodar rapidamente, em poucos segundos

18. Devem rodar rapidamente, em poucos segundos
Feedback rápido!

19. Seu código vai sofrer um impacto grande a partir
do momento que começar a escrever testes e
refatorar

20. Seu código vai sofrer um impacto grande a partir
do momento que começar a escrever testes e
refatorar
Como assim?

21. Red - Green - Refactor

22. Exemplo :-D
(Java)
(Camada de modelo)

23. O que estou testando?

24. Se esse método reflete
o Enum

25. Menor unidade, lembra?

26. Testes de integração

27. Rodam mais lentamente

28. Fazem operações num
banco de dados
Ou no sistema de arquivos
Existe I/O

29. Para que?
Meus dados estão vindo de forma correta?
Meus dados estão sendo gravados de forma correta?
Minha camada de modelo está se comunicando corretamente com o ORM?

30. Que ferramentas posso usar?
Java Ruby

31. Testes de aceitação

32. Pra que?

33. Minha aplicação está com a camada de serviços bem testada

34. E a integração com a camada de visão?

35. JavaScript não funciona!
Text
Text
Text

36. Que ferramentas uso?

37. Que ferramentas uso?

38. Eu testo toda a aplicação?

39. Eu testo toda a aplicação?
Depende.

40. Porque?

41. Porque?
Testes de aceitação demoram mais a rodar

42. Porque?
Testes de aceitação demoram mais a rodar
Tem feedback demorado

43. Porque?
Testes de aceitação demoram mais a rodar
Tem feedback demorado
Escrever os testes também demora

44. Porque?
Testes de aceitação demoram mais a rodar
Tem feedback demorado
Escrever os testes também demora
Ou seja...

45. Demora!

46. Por isso...

47. Por isso...
É aconselhável testar apenas as telas mais importantes

48. Por isso...
É aconselhável testar apenas as telas mais importantes
Telas mais utilizadas ou com nível de complexidade maior

49. Por isso...
É aconselhável testar apenas as telas mais importantes
Telas mais utilizadas ou com nível de complexidade maior
Contanto que faça!

50. Junte tudo
Testes unitários + de integração + de aceitação
E coloque em um servidor de integração contínua

51. Existem vários
Jenkins TeamCity CruiseControl

52. Feedback rápido!

53. Feedback rápido!
Via email

54. Feedback rápido!
Via email
Via IDE

55. Feedback rápido!
Via email
Via IDE
Via IDE

56. Feedback rápido!
Via email
Via IDE
Via IDE
Via IM

57. Feedback rápido!
Via email
Via IDE
Via IDE
Via IM
...

58. Quanto antes você for avisado
que algo está errado, melhor!

59. Para concluir...

60. Para concluir...
Teste suas aplicações

61. Para concluir...
Teste suas aplicações
Todo mundo agradece, lembra?

62. Você Cliente

63. Todos felizes :-D