Test des applications EF Core

Le test est un problème important pour presque tous les types d’applications : il vous permet de vous assurer que votre application fonctionne correctement et le fait connaître instantanément si son comportement régresse à l’avenir. Étant donné que les tests peuvent affecter la façon dont votre code est conçu, il est vivement recommandé de planifier les tests 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)

Lorsque vous écrivez des tests pour votre application EF Core, une décision de base à prendre consiste à déterminer si vos tests impliquent votre système de base de données de production , comme votre application le fait , ou si vos tests s’exécutent sur un double de test, qui remplace votre système de base de données de production. Deux exemples importants de doubles de test dans le contexte d'EF Core sont SQLite en mode 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 informer rapidement sur 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 plusieurs façons importantes. Certaines fonctionnalités ne peuvent pas être testées pas du tout (par exemple, les transactions, SQL brut..), alors que d’autres peuvent se comporter différemment de la base de données de production (par exemple, la sensibilité à la casse dans les requêtes). Bien que le traitement en mémoire puisse convenir à des scénarios de requêtes simples et contraints, il est très limité, et nous en déconseillons l'utilisation.
  • DbSet La simulation de l’interrogation est complexe et difficile, et souffre des mêmes inconvénients que l’approche en mémoire ; nous déconseillons cela aussi.
• 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. Fonctions).
• 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 complètement le référentiel ; Toutefois, cela modifie l’architecture de votre application d’une manière qui pourrait être significative et implique davantage de coûts d’implémentation et de maintenance.

Lectures complémentaires

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.