Isolar código em teste com Microsoft Fakes

O isolamento de código é uma estratégia de teste geralmente implementada com ferramentas como Microsoft Fakes, em que o código que você está testando é separado do restante do aplicativo. Essa separação é obtida substituindo partes da aplicação que interagem com o código sob teste por stubs ou shims. Essas são pequenas partes de código controladas por seus testes, que simulam o comportamento das partes reais que estão substituindo.

O benefício dessa abordagem é que ela permite que você se concentre em testar a funcionalidade específica do código isoladamente. Se um teste falhar, você saberá que a causa está dentro do código isolado e não em outro lugar. Além disso, o uso de stubs e shims, fornecidos pelo Microsoft Fakes, permite testar seu código mesmo que outras partes do aplicativo ainda não estejam funcionando.

Requirements

Note

A criação de perfil com Visual Studio não está disponível para testes que usam Microsoft Fakes.

O papel do Microsoft Fakes no isolamento de código

Microsoft Fakes desempenha um papel fundamental no isolamento de código fornecendo dois mecanismos : stubs e shims.

  • Stubs: eles são usados para substituir uma classe por um pequeno substituto que implementa a mesma interface. Isso requer que seu aplicativo seja projetado de modo que cada componente dependa apenas de interfaces, não de outros componentes.

  • Shims: eles são usados para modificar o código compilado do aplicativo em runtime. Em vez de fazer uma chamada de método especificada, o aplicativo executa o código shim que o teste fornece. Os shims podem substituir chamadas para assemblies que você não pode modificar, como assemblies do .NET.

Normalmente, stubs são usados para chamadas dentro da sua solução do Visual Studio, e shims para chamadas a outros assemblies referenciados. Isso ocorre porque, em sua solução, é uma boa prática desacoplar os componentes definindo interfaces da maneira que o stubbing requer. No entanto, assemblies externos geralmente não vêm com definições de interface separadas, portanto, os shims são usados em vez disso.

Diagrama que mostra Fakes substituindo outros componentes.

Recomendações sobre quando usar stubs

Os stubs normalmente são usados para chamadas em sua solução de Visual Studio porque é uma boa prática desacoplar os componentes definindo interfaces da maneira que o stubbing exige. No entanto, assemblies externos, como System.dll, normalmente não são acompanhados de definições de interface separadas; nesses casos, seriam usados shims.

O uso de stubs envolve a criação de seu aplicativo para que os diferentes componentes não dependam uns dos outros, mas apenas em definições de interface. Esse desacoplamento torna a aplicação mais robusta e flexível, e permite que você conecte o componente em teste a implementações stub das interfaces para fins de teste.

Na prática, você pode gerar tipos de stub das definições de interface em Visual Studio e, em seguida, substituir o componente real pelo stub em seu teste.

Recomendações sobre quando usar shims

Embora os stubs sejam usados para chamadas na sua solução do Visual Studio, os shims normalmente são usados para chamadas a outras assemblies referenciadas. Isso ocorre porque assemblies externos, como System.dll, geralmente não são fornecidos com definições de interface separadas, portanto shims devem ser usados em vez disso.

No entanto, há alguns fatores a serem considerados ao usar shims:

Desempenho: os shims são executados mais lentamente porque reescrevem seu código em runtime. Os stubs não têm essa sobrecarga de desempenho e são tão rápidos quanto os métodos virtuais podem ser executados.

Métodos estáticos, tipos lacrados: você só pode usar stubs para implementar interfaces. Portanto, os tipos de stub não podem ser usados para métodos estáticos, métodos não virtuais, métodos virtuais lacrados, métodos em tipos lacrados e assim por diante.

Tipos internos: Tanto stubs quanto shims podem ser usados com tipos internos que são tornados acessíveis pelo uso do atributo de assembly InternalsVisibleToAttribute.

Métodos privados: Shims podem substituir chamadas para métodos privados se todos os tipos na assinatura do método estiverem visíveis. Os stubs só podem substituir métodos visíveis.

Interfaces e métodos abstratos: os Stubs fornecem implementações de interfaces e métodos abstratos que podem ser usados no teste. Os shims não podem instrumentar interfaces e métodos abstratos, pois não têm corpos de método.

Migrando o Microsoft Fakes no .NET Framework para projetos no estilo SDK

Migrando seus projetos de teste em .NET Framework que usam o Microsoft Fakes para projetos no estilo SDK em .NET Framework, .NET Core ou .NET 5+.

Você precisará fazer apenas alterações mínimas na configuração do .NET Framework para fazer a transição do Microsoft Fakes para o .NET Core ou o .NET 5.0. Os casos que você teria que considerar são:

  • Se você estiver usando um modelo de projeto personalizado, precisará garantir que ele siga o estilo SDK e seja compilado para um framework de destino compatível.

  • Determinados tipos existem em assemblies diferentes no .NET Framework e .NET Core/.NET 5.0 (por exemplo, System.DateTime existe em System/mscorlib no .NET Framework e em System.Runtime no .NET Core e .NET 5.0) e nesses cenários você precisa alterar o assembly que está sendo falsificado.

  • Se você tiver uma referência de assembly para um assembly fictício e para o projeto de teste, poderá ver um aviso de compilação sobre uma referência ausente semelhante a:

    (ResolveAssemblyReferences target) ->
warning MSB3245: Could not resolve this reference. Could not locate the assembly "AssemblyName.Fakes". Check to make sure the assembly exists on disk.
If this reference is required by your code, you may get compilation errors.

    Esse aviso se deve às alterações necessárias feitas na geração de Fakes e pode ser ignorado. Ele pode ser evitado removendo a referência de assembly do arquivo de projeto, pois agora os adicionamos implicitamente durante o build.

Executando testes do Microsoft Fakes

Contanto que as assemblies do Microsoft Fakes estejam presentes no diretório FakesAssemblies configurado (sendo $(ProjectDir)FakesAssemblies o padrão), você pode executar testes usando a tarefa vstest.

O teste distribuído com a tarefa vstest em projetos .NET Core e .NET 5 ou superior que usam o Microsoft Fakes requer o Visual Studio 2019 Update 9 Preview 20201020-06 ou superior.

Compatibilidade e suporte para Microsoft Fakes em diferentes versões de .NET e Visual Studio

Microsoft Fakes em projetos mais antigos direcionados ao .NET Framework (estilo não SDK).

  • A geração de assembly do Microsoft Fakes é compatível com o Visual Studio Enterprise 2015 e versões superiores.
  • Os testes do Microsoft Fakes podem ser executados com todos os pacotes NuGet Microsoft.TestPlatform disponíveis.
  • Há suporte à cobertura de código para projetos de teste que usam o Microsoft Fakes no Visual Studio Enterprise 2015 e versões posteriores.

Microsoft Fakes em projetos no estilo SDK do .NET Framework, .NET Core e .NET 5.0 ou posteriores

  • A geração de assemblies Fakes da Microsoft foi disponibilizada em versão prévia no Visual Studio Enterprise 2019 Atualização 6 e é habilitada por padrão na Atualização 8.
  • Os testes do Microsoft Fakes para projetos destinados ao .NET Framework podem ser executados com todos os pacotes NuGet Microsoft.TestPlatform disponíveis.
  • Os testes do Microsoft Fakes para projetos destinados ao .NET Core e ao .NET 5.0 ou posterior podem ser executados com pacotes NuGet do Microsoft.TestPlatform nas versões 16.9.0-preview-20210106-01 e posteriores.
  • Há suporte para cobertura de código para projetos de teste direcionados ao .NET Framework usando Microsoft Fakes no Visual Studio Enterprise versão 2015 e superior.
  • O suporte à cobertura de código para projetos de teste destinados ao .NET Core e ao .NET 5.0 ou posterior que usam o Microsoft Fakes está disponível no Visual Studio 2019, atualização 9 e posteriores.

Conteúdo relacionado

  • Last updated on