Isolar código em teste com Microsoft Fakes

O isolamento de código é uma estratégia de testes frequentemente implementada com ferramentas como a Microsoft Fakes, onde o código que está a testar é separado do resto da aplicação. Esta separação é conseguida substituindo partes da aplicação que interagem com o código em teste por stubs ou shims. São pequenos pedaços de código controlados pelos teus testes, que simulam o comportamento das peças que estão a substituir.

A vantagem desta abordagem é que permite focar-se em testar a funcionalidade específica do código isoladamente. Se um teste falhar, sabe-se que a causa está dentro do código isolado e não noutro local. Além disso, o uso de stubs e shims, fornecidos pela Microsoft Fakes, permite-lhe testar o seu código mesmo que outras partes da sua aplicação ainda não estejam a funcionar.

Requisitos

Note

O perfilamento com o Visual Studio não está disponível para testes que usam Microsoft Fakes.

O Papel da Microsoft Fakes no Isolamento de Código

A Microsoft Fakes desempenha um papel fundamental no isolamento do código ao fornecer dois mecanismos – stubs e shims.

  • Stubs: Estes são usados para substituir uma classe por um pequeno substituto que implementa a mesma interface. Isto exige que a sua aplicação seja desenhada de forma a que cada componente dependa apenas das interfaces, e não dos outros componentes.

  • Shims: São usados para modificar o código compilado da sua aplicação em tempo de execução. Em vez de fazer uma chamada de método especificada, a aplicação executa o código shim que o seu teste fornece. Os shims podem substituir chamadas para assemblagens que não é possível modificar, como as assemblagens do .NET.

Normalmente, os stubs são usados para chamadas na sua solução do Visual Studio, e os shims para chamadas a outros assemblies referenciados. Isto porque, dentro da sua solução, é boa prática desacoplar os componentes definindo interfaces da forma que o stubbing exige. No entanto, as assemblagens externas muitas vezes não incluem definições de interface separadas, pelo que se recorre antes a shims.

Diagrama que mostra simulacros a substituir outros componentes.

Recomendações sobre quando utilizar stubs

Os stubs são normalmente usados para chamadas dentro da sua solução Visual Studio porque é uma boa prática desacoplar os componentes definindo interfaces da forma que o stubbing exige. No entanto, conjuntos externos, como System.dll, normalmente não são fornecidos com definições de interface separadas, pelo que nesses casos seriam usados calços.

Usar stubs envolve desenhar a sua aplicação de modo a que os diferentes componentes não dependam uns dos outros, mas apenas das definições da interface. Este desacoplamento torna a aplicação mais robusta e flexível, permitindo ligar o componente em teste a implementações stub das interfaces para fins de teste.

Na prática, podes gerar tipos de stub a partir das definições da interface no Visual Studio e depois substituir o componente real pelo stub no teu teste.

Recomendações sobre quando utilizar calços

Embora os stubs sejam usados para chamadas dentro da sua solução Visual Studio, os shims são normalmente usados para chamadas a outros assemblies referenciados. Isto deve-se ao facto de conjuntos externos como System.dll normalmente não serem fornecidos com definições de interface separadas, pelo que devem ser usados calços em vez disso.

No entanto, há alguns fatores a considerar ao utilizar calços:

Desempenho: Os shims funcionam mais devagar porque reescrevem o teu código em tempo de execução. Os stubs não têm essa sobrecarga de desempenho e são tão rápidos quanto os métodos virtuais conseguem executar.

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

Tipos internos: Tanto stubs como shims podem ser usados com tipos internos tornados acessíveis através do atributo de assembly InternalsVisibleToAttribute.

Métodos privados: Os shims podem substituir chamadas para métodos privados se todos os tipos na assinatura do método forem 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 em testes. Os shims não podem instrumentar interfaces e métodos abstratos, porque não têm corpo de método.

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

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

Vai precisar de alterações mínimas no seu framework .NET configurado para que a Microsoft Fakes faça a transição para .NET Core ou .NET 5.0. Os casos que terá de considerar são:

  • Se estiveres a usar um template de projeto personalizado, tens de garantir que é ao estilo SDK e que se constrói para um framework de destino compatível.

  • Existem certos tipos 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 nestes cenários é necessário alterar a montagem que está a ser falsificada.

  • Se tiver uma referência de montagem para uma montagem falsa e para o projeto de teste, pode ver um aviso de construção sobre uma referência em falta 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.

    Este aviso deve-se a alterações necessárias efetuadas na geração de Fakes e pode ser ignorado. Isto pode ser evitado removendo a referência assembly do ficheiro do projeto, porque agora as adicionamos implicitamente durante a compilação.

Executar testes do Microsoft Fakes

Desde que as assemblies Fakes da Microsoft estejam presentes no diretório configurado FakesAssemblies (sendo $(ProjectDir)FakesAssemblies a predefinição), pode executar os testes usando a tarefa vstest.

Os testes distribuídos com a tarefa vstest para projetos .NET Core e .NET 5+ que utilizam o Microsoft Fakes requerem o Visual Studio 2019 Update 9 Preview 20201020-06 ou posterior.

Compatibilidade e Suporte para Microsoft Fakes em Diferentes Versões .NET e Visual Studio

A Microsoft falsifica em projetos antigos direcionados ao .NET Framework (estilo não-SDK).

  • A geração de assemblagens Microsoft Fakes é suportada no Visual Studio Enterprise 2015 e em versões posteriores.
  • Os testes Microsoft Fakes podem ser executados com todos os pacotes NuGet Microsoft.TestPlatform disponíveis.
  • A cobertura de código é suportada para projetos de teste que utilizam Microsoft Fakes no Visual Studio Enterprise 2015 e versões superiores.

Microsoft falsifica projetos ao estilo SDK de .NET Framework, .NET Core e .NET 5.0 ou posteriores

  • A geração de assemblagens do Microsoft Fakes foi apresentada em pré-visualização no Visual Studio Enterprise 2019 Update 6 e é ativada por predefinição na Atualização 8.
  • Os testes Microsoft Fakes para projetos destinados ao .NET Framework podem ser executados com todos os pacotes NuGet Microsoft.TestPlatform disponíveis.
  • Os testes Microsoft Fakes para projetos destinados ao .NET Core e ao .NET 5.0 ou posterior podem ser executados com os pacotes NuGet Microsoft.TestPlatform com versões 16.9.0-preview-20210106-01 e superiores.
  • A cobertura de código é suportada para projetos de teste destinados ao .NET Framework que utilizam o Microsoft Fakes no Visual Studio Enterprise, na versão 2015 e posteriores.
  • O suporte à cobertura de código para projetos de teste destinados ao .NET Core e ao .NET 5.0 e versões posteriores que utilizam o Microsoft Fakes está disponível no Visual Studio 2019 Update 9 e posteriores.

Conteúdo relacionado

  • Last updated on