Isolar o código em teste com elementos fictícios da Microsoft
O isolamento de código é uma estratégia de teste geralmente implementada com ferramentas, como o Microsoft Fakes, em que o código que você está testando é separado do restante do aplicativo. Essa separação é obtida substituindo partes do aplicativo que interagem com o código em teste por stubs ou shims. São pequenos trechos de código controlados por seus testes, que simulam o comportamento dos trechos 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.
Requisitos
- Visual Studio Enterprise
- Um projeto do .NET Framework
- O suporte a projetos no estilo do SDK, do .NET Core e do .NET 5.0 ou posterior estava em versão prévia no Visual Studio 2019 Atualização 6 e está habilitado por padrão na Atualização 8. Para obter mais informações, confira Microsoft Fakes para projetos no estilo .NET Core e SDK.
Observação
A criação de perfil com o Visual Studio não está disponível para testes que usam Microsoft Fakes.
A função do Microsoft Fakes no isolamento de código
O Microsoft Fakes desempenha um papel fundamental no isolamento de código fornecendo dois mecanismos: stubs e shims.
Stubs: 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: 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 de shim fornecido por seu teste. Shims podem substituir chamadas para assemblies que você não pode modificar, como assemblies .NET.
Em geral, stubs são usados para chamadas em 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 exigida pelo stub. No entanto, os assemblies externos geralmente não vêm com definições de interface separadas. Por isso, os shims são usados.
Recomendações sobre quando usar stubs
Os stubs normalmente são usados para chamadas em sua solução do Visual Studio porque é uma boa prática desacoplar os componentes definindo interfaces da maneira que o stub exige. No entanto, assemblies externos, como System.dll, normalmente não são fornecidos com definições de interface separadas, portanto, os shims seriam usados nesses casos.
O uso de stubs envolve projetar seu aplicativo para que os diferentes componentes não dependam uns dos outros, mas apenas das definições de interface. Desacoplar torna o aplicativo mais robusto e flexível, e permite conectar o componente em teste às implementações de stubs das interfaces para fins de teste.
Na prática, você pode gerar tipos de stub das definições de interface no Visual Studio e substituir o componente real pelo stub no teste.
Recomendações sobre quando usar shims
Embora os stubs sejam usados para chamadas em sua solução do Visual Studio, os shims normalmente são usados para chamadas para outros assemblies referenciados. Isso ocorre porque assemblies externos, como System.dll, geralmente não são fornecidos com definições de interface separadas. Portanto, os shims devem ser usados.
No entanto, há alguns fatores a serem considerados ao usar shims:
Desempenho: os shims têm execução mais lenta porque reescrevem o código no runtime. Os stubs não têm essa sobrecarga de desempenho e são tão rápidos quanto os métodos virtuais.
Métodos estáticos, tipos selados: você só pode usar stubs para implementar interfaces. Portanto, os tipos stub não podem ser usados para métodos estáticos, métodos não virtuais, métodos virtuais selados, métodos em tipos selados e assim por diante.
Tipos internos: os stubs e shims podem ser usados com tipos internos que são acessíveis com o atributo de assembly InternalsVisibleToAttribute.
Métodos particulares: os shims poderão substituir chamadas para métodos particulares 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 oferecem 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 eles não têm corpos de método.
Transição do Microsoft Fakes no .NET Framework para projetos no estilo SDK
Transição de projetos de teste do .NET Framework que usam o Microsoft Fakes para projetos no estilo SDK do .NET Framework, .NET Core ou .NET 5 ou posteriores.
Você precisará de alterações mínimas em sua configuração do .NET Framework para o Microsoft Fakes fazer a transição 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 seja de estilo de SDK e que seja compilado para uma estrutura de destino compatível.
Determinados tipos existem em assemblies diferentes no .NET Framework e no .NET Core/.NET 5.0 (por exemplo,
System.DateTimeexiste emSystem/mscorlibno .NET Framework e emSystem.Runtimeno .NET Core e no .NET 5.0), e nesses cenários você precisa alterar o assembly que está sendo simulado.Se você tiver uma referência de assembly a um assembly do Fakes e ao projeto de teste, poderá ver um aviso de build 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 ocorre devido às alterações necessárias feitas na geração do 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
Desde que os assemblies do Microsoft Fakes estejam presentes no diretório FakesAssemblies configurado (o padrão é $(ProjectDir)FakesAssemblies), você poderá executar testes usando a tarefa vstest.
Testes distribuídos com a tarefa vstest de projetos .NET Core e .NET 5 ou posteriores usando o Microsoft Fakes requerem o Visual Studio 2019 Atualização 9 Versão Prévia 20201020-06 e superior.
Compatibilidade e suporte para o Microsoft Fakes em diferentes versões do .NET e do Visual Studio
Microsoft Fakes em projetos mais antigos direcionados ao .NET Framework (que não são de estilo de SDK).
- A geração de assembly do Microsoft Fakes tem suporte no Visual Studio Enterprise 2015 e superior.
- Testes do Microsoft Fakes podem ser executados com todos os pacotes NuGet Microsoft.TestPlatform disponíveis.
- Há suporte para cobertura de código para projetos de teste usando o Microsoft Fakes no Visual Studio Enterprise 2015 e superior.
Microsoft Fakes em projetos em estilo de SDK do .NET Framework, .NET Core e .NET 5.0 ou posterior
- A geração de assembly do Microsoft Fakes é visualizada no Visual Studio Enterprise 2019 Atualização 6 e está habilitada por padrão na Atualização 8.
- Testes do Microsoft Fakes para projetos direcionados ao .NET Framework podem ser executados com todos os pacotes NuGet Microsoft.TestPlatform disponíveis.
- Testes do Microsoft Fakes para projetos direcionados ao .NET Core e ao .NET 5.0 ou posterior podem ser executados com pacotes NuGet Microsoft.TestPlatform com as versões 16.9.0-preview-20210106-01 e superiores.
- Há suporte para cobertura de código para projetos de teste direcionados ao .NET Framework usando o Microsoft Fakes no Visual Studio Enterprise versão 2015 e superior.
- O suporte à cobertura de código para projetos de teste direcionados ao .NET Core e ao .NET 5.0 ou posterior usando o Microsoft Fakes está disponível no Visual Studio 2019 atualização 9 e superior.