Det finns ett par SO-svar relaterade till enhetstestningskod som använder MongoDB som datalager:
- Hånar databasen i node.js?
- Mock/Test Mongodb Database Node.js
- Inbäddad MongoDB vid körning av integrationstester
- Liknande:Enhetstestklasser som har onlinefunktioner
Jag ska göra ett försök att konsolidera dessa lösningar.
Ingress
Först och främst bör du vill att MongoDB ska köras medan du utför dina tester. MongoDB:s frågespråk är komplext, så att köra legitima frågor mot en stabil MongoDB-instans krävs för att säkerställa att dina frågor körs som planerat och att din applikation svarar korrekt på resultaten. Med detta i åtanke bör du dock aldrig kör dina tester mot ett produktionssystem, men istället ett perifert system till din integrationsmiljö. Detta kan vara på samma maskin som din CI-programvara, eller helt enkelt relativt nära den (processmässigt, inte nödvändigtvis nätverk eller geografiskt sett).
Denna ENV kan vara låg fotavtryck och helt köras i minnet (resurs 1) (resurs 2), men skulle inte nödvändigtvis kräva samma prestandaegenskaper som din produktions ENV. (Om du vill testa prestanda bör detta ändå hanteras i en separat miljö från din CI.)
Inställningar
- Installera en
mongodtjänst specifikt för CI. Om repl-uppsättningar och/eller sharding är oroande (t.ex. skrivproblem, ingen användning av$isolated, etc.), är det möjligt att efterlikna en klustrad miljö genom att köra fleramongodinstanser (1 config, 2x2 data för shard+repl) och enmongosinstans på samma maskin med antingen några init.d-skript/tweaks eller något som docker. - Använd miljöspecifika konfigurationer i din applikation (antingen inbäddad via .json-filer, eller på någon plats som /etc, /home/user/.your-app eller liknande). Din applikation kan ladda dessa baserat på en nodmiljövariabel som
NODE_ENV=int. Inom dessa konfigurationer kommer dina db-anslutningssträngar att skilja sig åt. Om du inte är det Använd env-specifika konfigurationer, börja göra detta som ett sätt att abstrahera applikationens körtidsinställningar (dvs. "lokal", "dev", "int", "pre", "prod", etc.). Jag kan tillhandahålla ett prov på begäran. - Inkludera testorienterade fixturer med din applikation/testsvit. Som nämnts i en av de länkade frågorna, stöder MongoDB:s Node.js-drivrutin vissa hjälpbibliotek:
mongodb-fixturesochnode-database-cleaner. Fixturer ger en fungerande och konsekvent datauppsättning för testning:se dem som en bootstrap.
Bygg/tester
- Rengör den associerade databasen med något som
node-database-cleaner. - Fylla dina fixturer i den nu tomma databasen med hjälp av
mongodb-fixtures. - Utför ditt byggande och test.
- Upprepa.
Å andra sidan...
Om du ändå bestämmer dig för att inte att köra MongoDB är det korrekta tillvägagångssättet (och du skulle inte vara den enda), då är det bäst att abstrahera dina datalagringssamtal från drivrutinen med en ORM (för hela applikationen, inte bara testning). Till exempel något som model påstår sig vara databasagnostisk, även om jag aldrig har använt det. Om du använder detta tillvägagångssätt skulle du fortfarande behöva fixturer och env-konfigurationer , men du skulle inte behöva installera MongoDB. Förbehållet här är att du är överlämnad till den ORM du väljer.