Explorando Microsoft Fakes

Waldyr FelixEspecialista em desenvolvimento webMicrosoft MVP e ALM Ranger

Porque testar o software

Mais segurança nas manutenções Assegurar que o que estava funcionando

continuará funcionando Garantir que o software está cumprindo todos

os requisitos de negócio Melhorar qualidade do código Uso de boas práticas de programação

Código monstro!

Ninguém tem bola de cristal

Pré requisitos para habilitar um código para testes

Arquitetura bem definida Separação de responsabilidades Usar interfaces Manter os métodos pequenos

Arquitetura Emergente

Injeção de dependência

Passar a dependência por parâmetro na classe Diminui o acoplamento entre classes Geralmente usa interfaces para fazer isso É um tipo de inversão de controle

NÃO

Injeção de dependência

Injeção de dependência

Começando com Microsoft Fakes

Stubs

Pequeno trecho de código que pode ser substituído por outro

Geralmente são métodos de uma interface No teste são criados métodos fake no lugar da

implementação Serve para isolar o sistema a ser testado Sem stubs sem testes

Stubs

Criando um Stub com MS Fakes

Criando um Stub com MS Fakes

Lidando com dependências que não podem ser isoladas

Nem sempre é possível utilizar injeção de dependência

Sistemas legados também precisam de testes unitários

Métodos estáticos (static) não podem ser tratados como stubs

Para estes cenários temos duas opções...

Encapsular a dependência

Usar Shim Types do MS Fakes

Torna possível testar código que antes não era “testável”

Intercepta a chamada em runtime para substituir o membro

Permite testar código que depende de chamadas estáticas, classes seladas e até métodos privados

Shim

Usando Shim types

Cenário testando ASP.NET MVCDEMO, DEMO, DEMO, DEMO...

O guia do Microsoft fakes

bit.ly/VsLiBE

Agradecimentos

Waldyr FelixEspecialista em desenvolvimento webBlog: waldyrfelix.netTwitter: @WaldyrFelixEmail: waldyrfelix@gmail.com