Test des applications EF Core

Le test est une préoccupation importante pour presque tous les types d’applications : il vous permet de vérifier que votre application fonctionne correctement et la rend immédiatement connue si son comportement régresse à l’avenir. Comme les tests peuvent affecter la façon dont votre code est architecturé, il est vivement recommandé de planifier des tests au plus tôt et de garantir une bonne couverture à mesure que votre application évolue. Cette section d’introduction fournit une vue d’ensemble rapide des différentes stratégies de test pour les applications utilisant EF Core.

Impliquer la base de données (ou non)

Lors de l’écriture de tests pour votre application EF Core, une décision de base à prendre est de savoir si vos tests impliquent votre système de base de données de production ( comme votre application ) ou si vos tests s’exécutent sur un double de test, ce qui remplace votre système de base de données de production. Deux exemples importants de doubles de test dans le contexte EF Core sont le mode SQLite en mémoire et le fournisseur en mémoire.

Pour une comparaison et une analyse approfondies des différentes approches, consultez Choisir une stratégie de test. Vous trouverez ci-dessous un bref résumé point par point pour vous aider à vous familiariser avec les différentes options :

• Les développeurs évitent fréquemment les tests sur leur système de base de données de production, car ils croient que cela est difficile ou lent. Cela n’est pas toujours vrai dans notre expérience, et nous vous suggérons de donner cette approche une chance : le test sur votre système de base de données de production fournit des techniques pour effectuer cette opération de manière fiable et efficace. L’écriture d’au moins certains tests sur votre base de données est généralement nécessaire dans tous les cas pour vous assurer que votre application fonctionne réellement sur votre base de données de production et que les tests qui n’impliquent pas la base de données peuvent être limités dans ce qu’ils vous permettent de tester (voir ci-dessous).
• Le fournisseur en mémoire ne se comporte pas comme votre base de données réelle de nombreuses façons importantes. Certaines fonctionnalités ne peuvent pas être testées du tout (par exemple, les transactions, SQL bruts. ) tandis que d’autres fonctionnalités peuvent se comporter différemment de celle de votre base de données de production (par exemple, respect de la casse dans les requêtes). Bien que la mémoire puisse fonctionner pour des scénarios de requête simples et limités, elle est très limitée et nous déconseillons son utilisation.
  • La simulation de DbSet pour l’interrogation est complexe et difficile, et souffre des mêmes inconvénients que l’approche en mémoire; nous le déconseillons également.
• Le mode en mémoire SQLite offre une meilleure compatibilité avec les bases de données relationnelles de production, car SQLite est lui-même une base de données relationnelle à part entière. Toutefois, il y aura toujours des différences importantes entre SQLite et votre base de données de production, et certaines fonctionnalités ne peuvent pas être testées du tout (par exemple, des méthodes spécifiques au fournisseur sur EF.Functions).
• Pour une approche de test qui vous permet d’utiliser un double de test fiable pour toutes les fonctionnalités de votre système de base de données de production, il est possible d’introduire une couche de référentiel dans votre application. Cela vous permet d’exclure entièrement EF Core des tests et de simuler entièrement le référentiel ; Toutefois, cela modifie l’architecture de votre application d’une manière qui pourrait être importante et implique davantage de coûts d’implémentation et de maintenance.

Pour aller plus loin

Pour plus d’informations détaillées, consultez Choisir une stratégie de test. Pour obtenir des instructions d’implémentation et des exemples de code, consultez Tests sur votre système de base de données de production et Test sans votre système de base de données de production.