Isoler le code en cours de test avec Microsoft Fakes

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 à tester 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, fournies par Microsoft Fakes, vous permet de tester votre code même si d'autres parties de votre application ne fonctionnent pas encore.

Exigences

Note

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

Rôle d’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 à des assemblages que vous ne pouvez pas modifier, comme les assemblages .NET.

En général, les stubs sont utilisés pour les appels au sein de votre solution Visual Studio, et les shims pour les appels à d’autres assemblages référencés. Cela est dû au fait que dans votre solution, il est recommandé de dissocier les composants en définissant des interfaces de la façon dont le stubbing nécessite. Cependant, les assemblages externes sont souvent dépourvus de définitions d’interfaces distinctes ; on utilise donc des shims à la place.

Diagramme montrant Fakes remplaçant d’autres composants.

Recommandations sur quand utiliser des stubs

Les stubs sont généralement utilisés lors des appels au sein de votre solution Visual Studio, car il est recommandé de dissocier les composants en définissant des interfaces de la manière requise par les stubs. Cependant, les assemblages externes, tels que System.dll, ne sont généralement pas fournis avec des définitions d’interface séparées ; on utilise donc à la place des shims 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. Ce découplage rend l’application plus robuste et flexible et vous permet de connecter le composant sous test aux implémentations 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 vers d’autres assemblages référencés. Cela s’explique par le fait que les assemblages externes, comme System.dll, ne sont généralement pas fournis avec des définitions d’interface distinctes ; il faut donc utiliser des shims à la place.

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

Performance: les shims sont plus lents, car ils réécrivent votre code à l’exécution. Les stubs n’ont pas ce surcoût en termes de performances et s’exécutent aussi rapidement que les méthodes virtuelles.

Méthodes statiques, types scellés : vous ne pouvez utiliser que des stubs pour implémenter des interfaces. Par conséquent, les types stub ne peuvent pas être utilisés pour les méthodes statiques, les méthodes non virtuelles, les méthodes virtuelles scellées, les méthodes dans les types scellés, et ainsi de suite.

Types internes : les stubs et les shims peuvent être utilisés avec des types internes 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 de la signature de méthode sont visibles. Les stubs ne peuvent remplacer que les 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 celles-ci n’ont pas de corps.

Transition d’Microsoft Fakes dans .NET Framework vers des projets SDK-Style

Transition de vos projets de test .NET Framework qui utilisent Microsoft Fakes vers des projets de .NET Framework, .NET Core ou .NET 5+ de style SDK.

Vous aurez besoin de modifications minimales dans votre infrastructure de .NET configuré pour Microsoft Fakes afin de passer à .NET Core ou .NET 5.0. Les cas que vous devrez prendre en compte sont les suivants :

  • Si vous utilisez un modèle de projet personnalisé, vous devez vous assurer qu’il est de type SDK et qu’il se compile pour un framework cible compatible.

  • Certains types se trouvent dans différents assemblys dans .NET Framework et .NET Core/.NET 5.0 (par exemple, System.DateTime se trouve dans System/mscorlib dans .NET Framework, et dans System.Runtime dans .NET Core et .NET 5.0), et dans ces scénarios, vous devez modifier l’assembly simulé.

  • Si vous avez une référence à un assembly factice et au projet de test, il se peut que vous voyiez un avertissement de compilation concernant une référence manquante semblable à ce qui suit :

    (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 lié aux modifications nécessaires apportées à la génération de Fakes et peut être ignoré. Cela peut être évité en supprimant la référence d’assembly du fichier de projet, car nous les ajoutons désormais implicitement lors de la génération.

Exécution de tests Microsoft Fakes

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

Les tests distribués avec la tâche vstest .NET Core et les projets .NET 5+ utilisant Microsoft Fakes nécessitent Visual Studio 2019 Update 9 Preview 20201020-06 et versions ultérieures.

Compatibilité et prise en charge des faux Microsoft dans différentes versions .NET et Visual Studio

Microsoft Fakes dans les anciens projets ciblant .NET Framework (de style non-SDK).

  • La génération d’assemblys Microsoft Fakes est prise en charge dans Visual Studio Enterprise 2015 et versions ultérieures.
  • Les tests Microsoft Fakes peuvent être exécutés 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 versions ultérieures.

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

  • La génération d’assembly Microsoft Fakes a été proposée en préversion dans Visual Studio Enterprise 2019 Update 6 et est activée par défaut dans Update 8.
  • Les tests Microsoft Fakes pour les projets qui ciblent .NET Framework peuvent s’exécuter avec tous les packages NuGet Microsoft.TestPlatform disponibles.
  • Les tests Microsoft Fakes pour les projets qui ciblent .NET Core et .NET 5.0 ou une version ultérieure peuvent s’exécuter avec les packages NuGet Microsoft.TestPlatform à partir de la version 16.9.0-preview-20210106-01.
  • La couverture du code est prise en charge pour les projets de test ciblant .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 utilisant Microsoft Fakes et ciblant .NET Core ainsi que .NET 5.0 ou une version ultérieure est disponible dans Visual Studio 2019 mise à jour 9 et ultérieures.

Contenu connexe

  • Last updated on