Renato Groffe
Julho/2015
 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
 Página no Facebook
https://www.facebook.com/RenatoGroffeSW
 Perfil no Facebook
https://www.facebook.com/renatogroff
 LinkedIn
http://br.linkedin.com/in/renatogroffe
 Visual Studio 2013
 xUnit 2.0.0
 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
 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
 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
 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
 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
 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
 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
 Criando um novo projeto de testes unitários:
 O menu TEST
 Executando os testes definidos em uma classe
 A janela Test Explorer e o resultado da execução de testes
unitários
 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
 Packages do xUnit.net em um projeto de testes (xUnit.net
e xUnit.net [Runners])
 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
 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
 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”
 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)
 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→
Teste unitário criado
criado com o framework
xUnit.net →
 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 →
 Eliminação de instruções duplicadas e eventuais melhorias
no código
Exemplo de classe
refatorada →
 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
 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)
 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):
 Link para download da solução de exemplo:
https://gallery.technet.microsoft.com/Test-Driven-Development-2aad5383
 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
 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
 Ajustando a classe de testes para que utilize os atributos
“Theory” e “InlineData” o resultado será:
 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”
 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?
Dúvidas, sugestões???
 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
Obrigado!!!

Test-Driven Development (TDD) utilizando o framework xUnit.net

  • 1.
  • 2.
     Mais de15 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 noFacebook https://www.facebook.com/RenatoGroffeSW  Perfil no Facebook https://www.facebook.com/renatogroff  LinkedIn http://br.linkedin.com/in/renatogroffe
  • 4.
     Visual Studio2013  xUnit 2.0.0
  • 5.
     Motivos quecontribuem 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
  • 7.
     A realizaçãode 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
  • 9.
     Retrabalho  Custosque 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
  • 11.
     Garantir queo 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 deunidade (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ísticascomumente 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 comoas 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
  • 15.
     Criando umnovo projeto de testes unitários:
  • 16.
  • 17.
     Executando ostestes definidos em uma classe
  • 18.
     A janelaTest Explorer e o resultado da execução de testes unitários
  • 19.
     O usodo 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 doxUnit.net em um projeto de testes (xUnit.net e xUnit.net [Runners])
  • 21.
     Um poucomais 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 baseadona 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 desoluçõ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çãode 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 elaboradoantes 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→
  • 26.
    Teste unitário criado criadocom o framework xUnit.net →
  • 27.
     Funcionalidade codificadada 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 deinstruções duplicadas e eventuais melhorias no código Exemplo de classe refatorada →
  • 29.
     Código maisclaro, 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 buscarum 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 detemperatura – Escala Fahrenheit para Celsius:  Classe a ser criada: C = (F – 32) / 1,8  Casos de teste (considerar 2 casas decimais para arredondamento):
  • 32.
     Link paradownload da solução de exemplo: https://gallery.technet.microsoft.com/Test-Driven-Development-2aad5383
  • 33.
     Cada casode 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 aclasse de testes para que utilize os atributos “Theory” e “InlineData” o resultado será:
  • 36.
     IntelliTest ◦ Novorecurso 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 aplicarTDD? ◦ Testando todas as funcionalidades da aplicação, sem exceções? ◦ Considerando apenas funcionalidades mais significativas do ponto de vista do negócio?
  • 38.
  • 39.
     Testes unitárioscom 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
  • 40.