Isolera kod under test med Microsoft Fakes

Kodisolering är en teststrategi som ofta implementeras med verktyg som Microsoft Fakes, där koden du testar är skild från resten av programmet. Denna separation uppnås genom att ersätta delar av programmet som interagerar med koden under test med stubs eller shims. Det här är små koddelar som styrs av dina tester, som simulerar beteendet för de faktiska delarna som de ersätter.

Fördelen med den här metoden är att du kan fokusera på att testa kodens specifika funktioner isolerat. Om ett test misslyckas vet du att orsaken finns i den isolerade koden och inte någon annanstans. Dessutom kan du med hjälp av stubs och shims, som tillhandahålls av Microsoft Fakes, testa din kod även om andra delar av programmet inte fungerar ännu.

Requirements

Note

Profilering med Visual Studio är inte tillgängligt för tester som använder Microsoft Fakes.

Rollen för Microsoft förfalskningar i kodisolering

Microsoft Fakes spelar en nyckelroll i kodisolering genom att tillhandahålla två mekanismer - stubs och shims.

  • Stubs: Dessa används för att ersätta en klass med ett litet substitut som implementerar samma gränssnitt. Detta kräver att ditt program utformas så att varje komponent endast beror på gränssnitt, inte på andra komponenter.

  • Shims: Dessa används för att ändra den kompilerade koden för ditt program vid körning. I stället för att göra ett angivet metodanrop kör programmet den shim-kod som testet tillhandahåller. Shims kan ersätta anrop till sammansättningar som du inte kan ändra, till exempel .NET sammansättningar.

Vanligtvis används stubs för anrop i din Visual Studio-lösning och shims för anrop till andra refererade sammansättningar. Detta beror på att det i din lösning är bra att frikoppla komponenterna genom att definiera gränssnitt på det sätt som stubbning kräver. Externa sammansättningar har dock ofta inte separata gränssnittsdefinitioner, så shims används i stället.

Diagram som visar förfalskningar som ersätter andra komponenter.

Rekommendationer om när stubs ska användas

Stubs används vanligtvis för anrop i din Visual Studio lösning eftersom det är en bra idé att frikoppla komponenterna genom att definiera gränssnitt på det sätt som stubbning kräver. Men externa sammansättningar, till exempel System.dll, tillhandahålls vanligtvis inte med separata gränssnittsdefinitioner, så shims skulle användas i dessa fall i stället.

Att använda stubs innebär att utforma ditt program så att de olika komponenterna inte är beroende av varandra, utan bara på gränssnittsdefinitioner. Den här avkopplingen gör programmet mer robust och flexibelt och gör att du kan ansluta komponenten under test till stub-implementeringar av gränssnitten i testsyfte.

I praktiken kan du generera stub-typer från gränssnittsdefinitionerna i Visual Studio och sedan ersätta den verkliga komponenten med stub i testet.

Rekommendationer om när du ska använda Shims

Även om anrop i din Visual Studio lösning används shims vanligtvis för anrop till andra refererade sammansättningar. Det beror på att externa sammansättningar som System.dll vanligtvis inte tillhandahålls med separata gränssnittsdefinitioner, så shims måste användas i stället.

Det finns dock några faktorer att tänka på när du använder shims:

Prestanda: Shims körs långsammare eftersom de skriver om koden vid körning. Stubs har inte den här prestandabelastningen och är så snabba som virtuella metoder kan köras.

Statiska metoder, förseglade typer: Du kan bara använda stubs för att implementera gränssnitt. Därför kan stub-typer inte användas för statiska metoder, icke-virtuella metoder, förseglade virtuella metoder, metoder i förseglade typer och så vidare.

Interna typer: Både stubs och shims kan användas med interna typer som görs tillgängliga med hjälp av sammansättningsattributet InternalsVisibleToAttribute.

Privata metoder: Shims kan ersätta anrop till privata metoder om alla typer av metodsignaturen visas. Stubs kan bara ersätta synliga metoder.

Gränssnitt och abstrakta metoder: Stubs tillhandahåller implementeringar av gränssnitt och abstrakta metoder som kan användas vid testning. Shims kan inte instrumentera gränssnitt och abstrakta metoder eftersom de inte har metodkroppar.

Övergå Microsoft förfalskningar i .NET Framework till SDK-Style projects

Överföra dina .NET Framework-testprojekt som använder Microsoft Fakes till SDK-liknande .NET Framework, .NET Core eller .NET 5+ projekt.

Du behöver minimala ändringar i din .NET Framework-konfiguration för Microsoft Fakes för att övergå till .NET Core eller .NET 5.0. De fall som du måste ta hänsyn till är:

  • Om du använder en anpassad projektmall måste du se till att den är SDK-stil och bygger för ett kompatibelt målramverk.

  • Vissa typer finns i olika sammansättningar i .NET Framework och .NET Core/.NET 5.0 (till exempel System.DateTime finns i System/mscorlib i .NET Framework och i System.Runtime i .NET Core och .NET 5.0), och i dessa scenarier måste du ändra sammansättningen som förfalskas.

  • Om du har en sammansättningsreferens till en förfalskningssammansättning och testprojektet kan du se en byggvarning om en referens som saknas som liknar:

    (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.

    Den här varningen beror på nödvändiga ändringar i genereringen av förfalskningar och kan ignoreras. Du kan undvika det genom att ta bort sammansättningsreferensen från projektfilen eftersom vi nu implicit lägger till dem under bygget.

Köra Microsoft Fakes-tester

Så länge Microsoft förfalskningssammansättningar finns i den konfigurerade katalogen FakesAssemblies (standardvärdet är $(ProjectDir)FakesAssemblies) kan du köra tester med hjälp av vstestuppgiften.

Distribuerad testning med vstest-uppgiften .NET Core och .NET 5+ projekt med Microsoft Fakes kräver Visual Studio 2019 Update 9 Preview 20201020-06 och senare.

Kompatibilitet och stöd för Microsoft förfalskningar i olika .NET och Visual Studio versioner

Microsoft Förfalskningar i äldre projekt som är inriktade på .NET Framework (icke-SDK-format).

  • Microsoft Fakes-sammansättningsgenerering stöds i Visual Studio Enterprise 2015 och senare.
  • Microsoft Fakes-tester kan köras med alla tillgängliga Microsoft. TestPlatform NuGet-paket.
  • Kodtäckning stöds för testprojekt som använder Microsoft Fakes i Visual Studio Enterprise 2015 och senare.

Microsoft Fakes i SDK-stil .NET Framework, .NET Core och .NET 5.0 eller senare projekt

  • Microsoft Fakes-sammansättningsgenereringen förhandsgranskas i Visual Studio Enterprise 2019 Update 6 och är aktiverad som standard i Uppdatering 8.
  • Microsoft Fakes-tester för projekt som riktar sig mot .NET Framework kan köras med alla tillgängliga Microsoft. TestPlatform NuGet-paket.
  • Microsoft Fakes-tester för projekt som riktar sig mot .NET Core och .NET 5.0 eller senare kan köras med Microsoft. TestPlatform NuGet-paket med versioner 16.9.0-preview-20210106-01 och senare.
  • Kodtäckning stöds för testprojekt som riktar sig till .NET Framework med hjälp av Microsoft Fakes i Visual Studio Enterprise version 2015 och senare.
  • Stöd för kodtäckning för testprojekt som riktar sig till .NET Core och .NET 5.0 eller senare med hjälp av Microsoft Fakes finns i Visual Studio uppdatering 9 2019 och senare.

Relaterat innehåll

  • Last updated on