Partager via

Isoler du code testé avec Microsoft Fakes

  • Article

L’isolation du code est une stratégie de test souvent implémentée avec des outils comme Microsoft Fakes, où le code que vous testez est séparé du reste de l’application. Cette séparation est obtenue en remplaçant les parties de l’application qui interagissent avec le code testé par des stubs ou des shims. Il s’agit de petits éléments de code contrôlés par vos tests, qui simulent le comportement des parties réelles qu’ils remplacent.

L’avantage de cette approche est qu’elle vous permet de vous concentrer sur le test des fonctionnalités spécifiques du code en isolation. Si un test échoue, vous savez que la cause se trouve dans le code isolé et pas ailleurs. En outre, l’utilisation de stubs et de shims, fournis par Microsoft Fakes, vous permet de tester votre code même si d’autres parties de votre application ne fonctionnent pas encore.

Configuration requise

  • Visual Studio Enterprise
  • Un projet .NET Framework
  • La prise en charge des projets .NET Core, .NET 5.0 ou version ultérieure, et des projets de type SDK est disponible en préversion dans Visual Studio 2019 Update 6. Elle est activée par défaut dans la version Update 8. Pour plus d’informations, consultez Microsoft Fakes pour les projets de type SDK et .NET Core.

Notes

Le profilage avec Visual Studio n’est pas disponible pour les tests qui utilisent Microsoft Fakes.

Rôle de Microsoft Fakes dans l’isolation du code

Microsoft Fakes joue un rôle clé dans l’isolation du code en fournissant deux mécanismes : stubs et shims.

  • Stubs: ceux-ci sont utilisés pour remplacer une classe par un petit substitut qui implémente la même interface. Cela nécessite que votre application soit conçue de telle sorte que chaque composant dépend uniquement des interfaces, et non des autres composants.

  • Shims: ceux-ci sont utilisés pour modifier le code compilé de votre application au moment de l’exécution. Au lieu d'effectuer un appel de méthode spécifié, l’application exécute le code shim fourni par votre test. Les shims peuvent remplacer les appels d’assemblys que vous ne pouvez pas modifier, par exemple les assemblys .NET.

Les stubs sont utilisés pour les appels au sein de votre solution Visual Studio, et des shims pour les appels d’autres assemblys référencés. En effet, dans votre solution, il est recommandé de découpler les composants en définissant les interfaces conformément à ce qui est imposé par l’opération stub. Toutefois, les assemblys externes ne sont souvent pas fournis avec des définitions d’interface distinctes. Par conséquent, les shims sont utilisés à la place.

Diagram that show Fakes replacing other components.

Recommandations sur quand utiliser des stubs

Les stubs sont généralement utilisés pour les appels au sein de votre solution Visual Studio, car il est recommandé de dissocier les composants en définissant des interfaces de la façon dont le stub nécessite. Toutefois, les assemblys externes, tels que System.dll, ne sont généralement pas fournis avec des définitions d’interface distinctes. Les shims sont donc utilisés dans ces cas.

L’utilisation de stubs implique la conception de votre application afin que les différents composants ne dépendent pas les uns des autres, mais uniquement sur les définitions d’interface. Cette séparation rend l'application plus fiable et plus flexible, et vous permet de connecter le composant testé à des implémentations de stub des interfaces à des fins de test.

Dans la pratique, vous pouvez générer des types stub à partir des définitions d’interface dans Visual Studio, puis remplacer le composant réel par le stub dans votre test.

Recommandations sur quand utiliser des shims

Bien que les stubs soient utilisés pour les appels au sein de votre solution Visual Studio, les shims sont généralement utilisés pour les appels à d’autres assemblys référencés. Cela est dû au fait que les assemblys externes tels que System.dll ne sont généralement pas fournis avec des définitions d’interface distinctes. Les shims doivent donc être utilisés à la place.

Toutefois, il existe certains facteurs à prendre en compte lors de l’utilisation de shims :

Performance : les shims s’exécutent plus lentement, car ils réécrivent votre code au moment de l’exécution. Les stubs ne subissent pas cette surcharge de performances et sont aussi rapides que les méthodes virtuelles.

Méthodes statiques, types scellés : vous ne pouvez utiliser que des stubs pour implémenter des interfaces. Ainsi, les types stub ne peuvent pas être utilisés pour les méthodes statiques, les méthodes non virtuelles, les méthodes virtuelles sealed, les méthodes dans les types sealed, etc.

Types internes : les stubs et les shims peuvent être utilisés avec les types internes qui sont rendus accessibles à l'aide de l'attribut d'assembly InternalsVisibleToAttribute.

Méthodes privées : les shims peuvent remplacer les appels aux méthodes privées si tous les types dans la signature de méthode sont visibles. Les stubs peuvent uniquement remplacer des méthodes visibles.

Interfaces et méthodes abstraites : Les stubs fournissent des implémentations d’interfaces et de méthodes abstraites qui peuvent être utilisées dans les tests. Les shims ne peuvent pas instrumenter les interfaces ni les méthodes abstraites, car ils n’ont pas de corps de méthode.

Transition de Microsoft Fakes dans .NET Framework vers des projets de style SDK

Effectuer la transition de vos projets de test du .NET Framework qui utilisent Microsoft Fakes vers des projets du .NET Framework, .NET Core, ou .NET 5+ de type SDK.

Vous aurez besoin d’apporter des changements minimaux à votre configuration du .NET Framework pour Microsoft Fakes afin d’effectuer la transition vers .NET Core ou .NET 5.0. Les cas à prendre en compte sont les suivants :

  • Si vous utilisez un modèle de projet personnalisé, vous devez vérifier qu’il est de type SDK, et qu’il génère des fichiers pour un framework cible compatible.

  • Certains types existent dans différents assemblys dans le .NET Framework et dans .NET Core/.NET 5.0 (par exemple, System.DateTime existe dans System/mscorlib dans le .NET Framework, et dans System.Runtime dans .NET Core et .NET 5.0). Vous devez donc changer l’assembly à simuler dans ces scénarios.

  • Si vous avez une référence d’assembly pour un assembly Fakes et le projet de test, vous pouvez voir un avertissement de build concernant une référence manquante, semblable à ceci :

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

    Cet avertissement est dû aux changements nécessaires apportés à la génération Fakes, et peut être ignoré. Vous pouvez l’éviter en supprimant la référence d’assembly du fichier projet, car nous les ajoutons désormais implicitement pendant la génération.

Exécution de tests Microsoft Fakes

Tant que les assemblys Microsoft Fakes sont présents dans le répertoire FakesAssemblies configuré (valeur par défaut : $(ProjectDir)FakesAssemblies), vous pouvez exécuter des tests à l’aide de la tâche vstest.

Si vous souhaitez effectuer des tests distribués avec la tâche vstest pour les projets .NET Core et .NET 5+ qui utilisent Microsoft Fakes, vous devez disposer de Visual Studio 2019 Update 9 Preview 20201020-06 ou version ultérieure.

Compatibilité et prise en charge de Microsoft Fakes dans différentes versions de .NET et Visual Studio

Microsoft Fakes dans les projets plus anciens ciblant le .NET Framework (non SDK).

  • La génération d’assemblys Microsoft Fakes est prise en charge dans Visual Studio Enterprise 2015 et les versions ultérieures.
  • Les tests Microsoft Fakes peuvent s’exécuter avec tous les packages NuGet Microsoft.TestPlatform disponibles.
  • La couverture du code est prise en charge pour les projets de test utilisant Microsoft Fakes dans Visual Studio Enterprise 2015 et les versions ultérieures.

Microsoft Fakes dans les projets du .NET Framework, .NET Core et .NET 5.0 ou version ultérieure de type SDK

  • La génération d’assemblys Microsoft Fakes est disponible en préversion dans Visual Studio Enterprise 2019 Update 6. Elle est activée par défaut dans la version Update 8.
  • Les tests Microsoft Fakes pour les projets qui ciblent le .NET Framework peuvent s’exécuter avec tous les packages NuGet Microsoft.TestPlatform disponibles.
  • Les tests Microsoft Fakes pour les projets qui ciblent le .NET Core et .NET 5.0 ou version ultérieure peuvent s’exécuter avec les packages NuGet Microsoft.TestPlatform, avec les versions 16.9.0-preview-20210106-01 et les versions ultérieures.
  • La couverture du code est prise en charge pour les projets de test ciblant le .NET Framework à l’aide de Microsoft Fakes dans Visual Studio Enterprise version 2015 et ultérieure.
  • La prise en charge de la couverture du code pour les projets de test ciblant .NET Core et .NET 5.0 ou une version ultérieure à l’aide de Microsoft Fakes est disponible dans Visual Studio 2019 Update 9 et version ultérieure.

Contenu connexe