Tópicos abordados:
- Motivos que contribuem para a falta de testes
- Quais os impactos da falta de testes?
- Visão geral dos diferentes tipos de testes na área de software
- Testes unitários e a plataforma .NET
- TDD: conceitos gerais
- Implementação de um exemplo prático
- Data-Driven Unit Testing
- Testes unitários e o Visual Studio 2015
2. Mais de 15 anos de experiência na área de Tecnologia
Pós-graduação em Engenharia de Software – ênfase em
SOA
MBA em Business Intelligence
Graduação em Sistemas de Informação
Técnico em Processamento de Dados
MTAC (Microsoft Technical Audience Contributor), MCP,
Microsoft Specialist, MCTS, OCA, ITIL, COBIT
3. Página no Facebook
https://www.facebook.com/RenatoGroffeSW
Perfil no Facebook
https://www.facebook.com/renatogroff
LinkedIn
http://br.linkedin.com/in/renatogroffe
5. Motivos que contribuem para a falta de testes
Quais os impactos da falta de testes?
Visão geral dos diferentes tipos de testes na área de software
Testes unitários e a plataforma .NET
TDD: conceitos gerais
Implementação de um exemplo prático
Data-Driven Unit Testing
Testes unitários e o Visual Studio 2015
6.
7. A realização de testes é muitas vezes negligenciada:
◦ Falta de planejamento
◦ Tempo escasso
◦ Equipes reduzidas e sobrecarregadas, trabalhando
simultaneamente em vários projetos
◦ Falta de hábito
◦ Excesso de confiança de alguns profissionais
8.
9. Retrabalho
Custos que excedem o orçamento
Conflitos entre membros de uma equipe técnica ou junto
à área de negócios
Prejuízos à imagem da equipe ou empresa responsável
por um projeto
10.
11. Garantir que o produto atende aquilo que foi especificado para o
projeto
◦ Verificação do correto funcionamento de uma aplicação
◦ Detecção de falhas e defeitos que poderiam passar em branco até
a subida em Produção
12. Teste de unidade (ou teste unitário): verificação das menores unidades
(método, classe, objeto) em um software, a fim de determinar a lógica de
uma estrutura sob análise
Teste de integração: análise do funcionamento em conjunto das diferentes
partes que compõem uma aplicação
Teste de sistema: simulação de uma situação real, em um ambiente
equivalente ao de Produção
Teste de aceitação: conduzidos por um grupo de usuários finais com o
intuito de simular operações cotidianas
Teste de regressão: verifica se mudanças introduzidas em uma versão
resultam em efeitos colaterais nas funcionalidades pré-existentes
13. São características comumente atribuídas aos testes unitários:
◦ São automatizados e repetíveis
◦ Podem ser implementados facilmente
◦ Uma vez escritos, os testes devem ser mantidos para reuso futuro
◦ Qualquer profissional envolvido com o desenvolvimento de uma
aplicação deve ser capaz de executá-los
◦ Facilmente acionáveis, com isto acontecendo a partir de um botão ou
item de menu dentro de uma IDE
◦ Rapidez na execução
14. Assim como as principais plataformas da atualidade, o
.NET Framework conta com diversas alternativas para a
implementação de testes unitários:
◦ Visual Studio Unit Testing Framework (MS Test)
◦ NUnit (http://www.nunit.org/)
◦ xUnit.net (https://github.com/xunit)
É possível integrar a utilização destes frameworks ao
processo de build de uma aplicação → O Team Foundation é
um bom exemplo de solução que suporta este tipo de
funcionalidade
18. A janela Test Explorer e o resultado da execução de testes
unitários
19. O uso do framework xUnit.net requer:
◦ A criação de um novo projeto de testes
◦ Referenciar a aplicação que será submetida a testes neste novo projeto
◦ A instalação de packages para a codificação de testes e execução dos
mesmos na IDE
◦ A criação de classes que conterão os testes
◦ A definição de métodos para checagens nessas classes de testes, com estes
últimos sendo marcados com os atributos “Fact” ou “Theory” e fazendo uso
de funções definidas na classe Assert
20. Packages do xUnit.net em um projeto de testes (xUnit.net
e xUnit.net [Runners])
21. Um pouco mais sobre a classe Assert:
◦ Definida no namespace Xunit
◦ Caso uma checagem produza como resultado o valor false,
considera-se que o teste em questão gerou um erro
◦ Alguns dos métodos disponibilizados por este tipo: Equal, NotEqual,
False, True, Null e NotNull
22. Desenvolvimento baseado na codificação de testes unitários
Abordagem que tem “início” em 2002, com a publicação do livro “Test-Driven
Development: By Example” por Kent Beck (“pai” do XP - Extreme Programming)
SUT (“System Under Test”) ou CUT (“Class Under Test” ou “Code Under Test”) →
alguns termos comuns dentro de TDD
23. Construção de soluções de uma maneira que facilite a integração a
ferramentas para a execução de testes unitários
Codificação de testes unitários antes mesmo da implementação
das partes que serão submetidas a análises → evitando assim a
elaboração de testes “viciados”
24. A implementação de uma funcionalidade segue um ciclo
conhecido como Red-Green-Refactor (com a execução
dos testes unitários em todos os estágios)
25. Teste elaborado antes mesmo da funcionalidade ter sido
codificada (apenas a estrutura básica foi definida), de
forma a se evitar uma verificação “viciada”
Exemplo de definição de classe
com funcionalidades ainda não
implementadas→
27. Funcionalidade codificada da forma mais simples
possível, de maneira a garantir a execução com sucesso
dos testes
Exemplo anterior com
funcionalidades já implementadas →
28. Eliminação de instruções duplicadas e eventuais melhorias
no código
Exemplo de classe
refatorada →
29. Código mais claro, já que os testes são escritos com o objetivo de checar
porções menos extensas de um projeto
Testes unitários podem ser encarados como uma forma de se documentar o
código → entendimento de como o método ou classe funciona
Um rápido feedback, com a geração de alertas diante de eventuais problemas →
algo extremamente importante ao se efetuarem testes de regressão
Uma maior cobertura de diferentes trechos de código, o que poderia não
acontecer com outros tipos de testes
Falhas são apontadas durante o desenvolvimento, economizando assim tempo
e recursos financeiros
30. Ao buscar um código mais simples e de fácil manutenção, a
adoção de TDD acaba por favorecer uma melhor assimilação de
boas práticas de desenvolvimento/arquitetura de software:
◦ Separação de Responsabilidades (ao isolar a lógica de negócios ou de
acesso a dados das camadas de visualização de uma aplicação)
◦ Maior coesão (evitando a implementação de classes “faz-tudo”)
◦ Menor acoplamento (a simplificação do código visando a escrita de
testes eficazes contribui para uma menor dependência entre diferentes
partes de uma aplicação)
31. Conversão de temperatura – Escala Fahrenheit para Celsius:
Classe a ser criada:
C = (F – 32) / 1,8
Casos de teste (considerar 2 casas decimais para arredondamento):
32. Link para download da solução de exemplo:
https://gallery.technet.microsoft.com/Test-Driven-Development-2aad5383
33. Cada caso de teste possui um método correspondente →
duplicação de código (ao menos para este exemplo
específico)
Casos de teste adicionais exigirão a implementação de
novos métodos para cada situação
34. Métodos parametrizados, com a utilização de
mecanismos para prover os valores a serem testados
xUnit.net
◦ Métodos marcados com o atributo “Theory”
◦ O atributo “InlineData” é utilizado para a especificação de valores,
estando associado a um método de teste
35. Ajustando a classe de testes para que utilize os atributos
“Theory” e “InlineData” o resultado será:
36. IntelliTest
◦ Novo recurso que permite a geração automática de casos de testes a
partir do Visual Studio 2015
◦ Anteriormente conhecido como “Smart Unit Tests”
37. Quando aplicar TDD?
◦ Testando todas as funcionalidades da aplicação, sem exceções?
◦ Considerando apenas funcionalidades mais significativas do ponto
de vista do negócio?
39. Testes unitários com o framework xUnit.net
http://social.technet.microsoft.com/wiki/pt-
br/contents/articles/31395.testes-unitarios-com-o-framework-
xunit-net.aspx
Novos recursos do Visual Studio 2015: Smart Unit Tests
http://netcoders.com.br/blog/visual-studio-2015-smart-unit-
tests/
Test-Driven Development
http://martinfowler.com/bliki/TestDrivenDevelopment.html
Unit Test
http://martinfowler.com/bliki/UnitTest.html