Introdução aos testes unitários automatizados com NUnit e C#

Transcript

1. Introdução aos testes unitários automatizados com NUnit e C#
2. - Testes Automatizados: Motivação - Problemas comuns com testes manuais - Dificuldades na Engenharia de Software - Panorama geral de testes automatizados - Testes Unitários com NUnit - Finalizando - Dúvidas comuns ao iniciar com teste unitário - Materiais de referência - Conclusão
3. http://carlosschults.net/unifai2017
4. testes automatizados?
5. testes automatizados? motivação
6. problemas comuns com testes manuais
7. #1.dificuldade em testar componente de maneira isolada.
8. LOGIN TELA 1 TELA 2 TELA 3
10. #2.dificuldade em reproduzir os testes fielmente.
11. LOGIN TELA 1 TELA 2 TELA 3
12. #3.lentidão.
13. #4.alto custo.
14. dificuldades na Engenharia de Software
15. #1.criar um design com baixo acoplamento.
16. #2.baixa confiança na hora de fazer alterações.
17. testes automatizados? panorama
18. testes automatizados? definição
19. “[...] automação de teste é o uso de software especial (separado do software sendo testado) para controlar a execução de testes e comparação dos resultados obtidos com os resultados previstos.” https://en.wikipedia.org/wiki/Test_automation
20. “[...] automação de teste é o uso de software especial (separado do software sendo testado) para controlar a execução de testes e comparação dos resultados obtidos com os resultados previstos.” https://en.wikipedia.org/wiki/Test_automation
23. testes unitários definição
24. “Um teste de unidade é um trecho de código automatizado que chama a unidade de trabalho sendo testada, e então checa algumas suposições sobre um único resultado final desta unidade. “ Roy Osherove, em The Art of Unit Testing With Examples In C#
25. “Um teste de unidade é um trecho de código automatizado que chama a unidade de trabalho sendo testada, e então checa algumas suposições sobre um único resultado final desta unidade. “ Roy Osherove, em The Art of Unit Testing With Examples In C#
26. Um teste não é unitário se: •Interage com o banco de dados. •Se comunica através da rede •Interage com o sistema de arquivos •Não pode ser executado ao mesmo tempo que outros testes •Você precisa fazer coisas especiais no seu ambiente (tal como editar arquivos de configuração) para executá-lo. Michael C. Feathers, autor de Trabalho Eficaz com Código Legado
27. Um teste não é unitário se: •Interage com o banco de dados. •Se comunica através da rede •Interage com o sistema de arquivos •Não pode ser executado ao mesmo tempo que outros testes •Você precisa fazer coisas especiais no seu ambiente (tal como editar arquivos de configuração) para executá-lo. Michael C. Feathers, autor de Trabalho Eficaz com Código Legado
28. Um teste não é unitário se: •Interage com o banco de dados. •Se comunica através da rede. •Interage com o sistema de arquivos •Não pode ser executado ao mesmo tempo que outros testes •Você precisa fazer coisas especiais no seu ambiente (tal como editar arquivos de configuração) para executá-lo. Michael C. Feathers, autor de Trabalho Eficaz com Código Legado
29. Um teste não é unitário se: •Interage com o banco de dados. •Se comunica através da rede. •Interage com o sistema de arquivos. •Não pode ser executado ao mesmo tempo que outros testes •Você precisa fazer coisas especiais no seu ambiente (tal como editar arquivos de configuração) para executá-lo. Michael C. Feathers, autor de Trabalho Eficaz com Código Legado
30. Um teste não é unitário se: •Interage com o banco de dados. •Se comunica através da rede. •Interage com o sistema de arquivos. •Não pode ser executado ao mesmo tempo que outros testes. •Você precisa fazer coisas especiais no seu ambiente (tal como editar arquivos de configuração) para executá-lo. Michael C. Feathers, autor de Trabalho Eficaz com Código Legado
31. Um teste não é unitário se: •Interage com o banco de dados. •Se comunica através da rede. •Interage com o sistema de arquivos. •Não pode ser executado ao mesmo tempo que outros testes. •Você precisa fazer coisas especiais no seu ambiente (tal como editar arquivos de configuração) para executá-lo. Michael C. Feathers, autor de Trabalho Eficaz com Código Legado
32. Um teste não é unitário se: •Interage com o banco de dados. •Se comunica através da rede. •Interage com o sistema de arquivos. •Não pode ser executado ao mesmo tempo que outros testes. •Você precisa fazer coisas especiais no seu ambiente (tal como editar arquivos de configuração) para executá-lo. Michael C. Feathers, autor de Trabalho Eficaz com Código Legado
33. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Deve executar rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
34. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Deve executar rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
35. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Deve executar rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
36. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Executa rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
37. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Executa rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
38. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Executa rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
39. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Executa rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
40. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Executa rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
41. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Executa rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
42. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Executa rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão.
43. Propriedades de um bom teste de unidade: •É automatizado e repetível. •É fácil de implementar. •Executa rapidamente. •Ainda será relevante amanhã. •Qualquer um pode executar clicando em um botão. •É consistente em seus resultados. •Tem total controle da unidade sob teste. •É completamente isolado de outros testes. •Quando falha, é fácil de identificar a razão. Roy Osherove, em The Art of Unit Testing With Examples In C#
44. testes de integração definição
46. testes unitários com Nunit parte prática
47. dúvidas frequentes sobre testes unitários
48. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que deve ser testado? •Quem deve escrever os testes? •Testes manuais devem ser abolidos?
49. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins?
50. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins? Verificando a mudança de estado causada por ele. testar
52. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins?
53. •Como testar métodos sem retorno (void)? •Como testar métodos privados? Você não deveria precisar.testar
54. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins?
55. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •Vendo o teste falhar.
56. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •Mantendo os testes simples e sem lógica.
57. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •Utilizando revisão de código.
58. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •Utilizando testes de mutação.
59. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •Não repetindo a implementação nos testes.
63. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins?
64. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que não deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins?
65. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que não deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins? Código trivial, como atribuição.
70. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que não deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins? Linguagem/Framework.
71. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que não deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins? Código que você não pode corrigir.
72. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que não deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins? Código gerado automaticamente.
73. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que deve ser testado? •Quem deve escrever os testes? •Testes manuais são ruins?
74. •Como testar métodos sem retorno (void)? •Como testar métodos privados? •Como saber que o teste está certo? •O que deve ser testado? •Quem deve escrever os testes? •Testes manuais devem ser abolidos?
75. referências & materiais para estudo
76. Código Limpo de Robert C. Martin
77. Test-Driven Development de Maurício Aniche
78. Trabalho Eficaz Com Código Legado de Michael Feathers
79. The Art of Unit Testing de Rob Osherov
80. http://carlosschults.net/unifai2017
81. Introdução aos testes unitários automatizados com NUnit e C#