EF Core-toepassingen testen

Testen is een belangrijke factor voor bijna alle toepassingstypen. Hiermee kunt u ervoor zorgen dat uw toepassing correct functioneert en wordt het direct duidelijk als het gedrag in de toekomst achteruitgaat. Omdat testen van invloed kunnen zijn op de manier waarop uw code is ontworpen, wordt het ten zeerste aanbevolen om vroeg te testen en een goede dekking te garanderen naarmate uw toepassing zich ontwikkelt. In deze inleidende sectie vindt u een kort overzicht van verschillende teststrategieën voor toepassingen die GEBRUIKMAKEN van EF Core.

Betrekken van de database (of niet)

Bij het schrijven van tests voor uw EF Core-toepassing moet u een basisbeslissing nemen: of uw tests betrekking hebben op uw productiedatabasesysteem, net zoals uw toepassing, of dat uw tests worden uitgevoerd op een testdubbel, waardoor uw productiedatabasesysteem wordt vervangen. Twee prominente voorbeelden van testdubbels in de EF Core-context zijn SQLite in-memory modus en de in-memory provider.

Zie Een teststrategie kiezen voor een diepgaande vergelijking en analyse van de verschillende benaderingen. Hieronder vindt u een kort overzicht van punten per punt, zodat u snel aan de slag kunt met de verschillende opties:

• Ontwikkelaars vermijden vaak testen op hun productiedatabasesysteem omdat ze denken dat dit moeilijk of traag is. Dit is niet altijd waar in onze ervaring en we raden u aan deze benadering een kans te geven: Testen op basis van uw productiedatabasesysteem biedt technieken om dit betrouwbaar en efficiënt te doen. Het schrijven van ten minste enkele tests voor uw database is meestal in elk geval noodzakelijk , om ervoor te zorgen dat uw toepassing daadwerkelijk werkt voor uw productiedatabase en tests die geen betrekking hebben op de database, kunnen worden beperkt in wat u kunt testen (zie hieronder).
• De provider in het geheugen gedraagt zich op veel belangrijke manieren niet als uw echte database. Sommige functies kunnen er helemaal niet mee worden getest (bijvoorbeeld transacties, onbewerkte SQL.).), terwijl andere functies zich mogelijk anders gedragen dan uw productiedatabase (bijvoorbeeld hoofdlettergevoeligheid in query's). Hoewel werken in het geheugen voor beperkte, eenvoudige queryscenario's mogelijk is, is het erg beperkt en raden we het gebruik ervan af.
  • Het mocken van query's met behulp van DbSet is complex en moeilijk, en heeft dezelfde nadelen als de benadering met in-memory opslag. We ontmoedigen dit ook.
• SQLite in-memory modus biedt betere compatibiliteit met relationele productiedatabases, omdat SQLite zelf een volwaardige relationele database is. Er zijn echter nog steeds enkele belangrijke verschillen tussen SQLite en uw productiedatabase en sommige functies kunnen helemaal niet worden getest (bijvoorbeeld providerspecifieke methoden op EF. Functies).
• Voor een testbenadering waarmee u een betrouwbare testdubbel kunt gebruiken voor alle functionaliteit van uw productiedatabasesysteem, is het mogelijk om een opslagplaatslaag in uw toepassing te introduceren. Hierdoor kunt u EF Core volledig uitsluiten van testen en volledig mocken van de opslagplaats; Dit verandert echter de architectuur van uw toepassing op een manier die aanzienlijk kan zijn en brengt meer implementatie- en onderhoudskosten met zich mee.

Meer lezen

Zie Een teststrategie kiezen voor meer gedetailleerde informatie. Zie Testen op basis van uw productiedatabasesysteem en Testen zonder uw productiedatabasesysteem voor implementatierichtlijnen en codevoorbeelden.