Sådan skriver du en Express JS-server ved hjælp af testudviklet udvikling

Del 1: Opsætning af miljøer

med tilladelse fra freecodecamp

Hvorfor TDD i første omgang?

Så du har sandsynligvis været i denne situation før, du skriver software. Det fungerer smukt - men kun få timer før den store præsentation. Du beslutter at foretage et par ændringer til et par metoder. Du kører applikationen, fungerer stadig - eller sådan tror du.

Det er tid til den præsentation, du kommer godt igennem de indledende dele af applikationen, indtil det er tid til at vise up-upload-funktionen, du lige har implementeret - så boom! Det fungerer ikke mere. Du prøver igen - boom ingenting, du begynder at få panik på dette tidspunkt. Du begynder at frygte at være programmør, du fortæller sandsynligvis din chef eller professor, at det fungerede, du sværger endda for det.

Det er her Test Driven Development kommer til undsætning. Det er praksis at skrive test, der tester, at din kode gør det, der skal. I denne praksis skriver du prøver, før du skrev den faktiske kode. For eksempel, hvis du har en funktion, der beregner summen af ​​to tal og returnerer den, skriver du en test, der kontrollerer, at den returnerede sum er den forventede.

Nu undrer du dig sikkert over, hvordan kan vi teste en funktion, der ikke er skrevet endnu, og vil den test ikke mislykkes? Ja, det antages i første omgang at mislykkes. Din test skal mislykkes, indtil du skriver den funktion, der returnerer den rigtige sum, når der findes to tal. Fordelen er, at disse test altid vil kontrollere, at hvis du foretager nogle ændringer af din kode, har du en mellemliggende måde at vide, om disse ændringer ikke har ødelagt noget. For mere læsning om emnet her en strålende artikel fra freeCodeCamp:

Hvad bygger vi?

Nu i denne tutorial vil jeg vise dig, hvordan du kan opbygge og teste din Express JS Server ved hjælp af Test Driven Development-metoden.

Vi skal bygge en lille server, der leverer API'er til mest populære film, søger efter film og nogle andre CRUD-funktioner.

Hvad har vi brug for?

  1. Express JS - Mest populære Node JS-serverramme.
  2. Config - Hjælper med at opsætte miljøer (udvikling, test og produktion).
  3. Debug - Vis kun logfiler i test- eller udviklingsmiljøer.
  4. Mongoose - En elegant ODM til MongoDB i Node JS.
  5. Mokka - testramme.
  6. Nodemon - Genstarter vores udviklingsserver automatisk.
  7. Chai - Vores TDD / BDD påståelsesbibliotek.
  8. Babel CLI - En Javascript-kompilator.
  9. SuperTest - HTTP-servertestbibliotek.
  10. Garn - Hurtig, pålidelig og sikker afhængighedsadministrator (du er fri til at bruge npm i stedet, skal du blot udskifte kommandoer med npm-ækvivalent)

Opsætning af ting

1. mkdir movie_server; cd-film_server
2. garn init
3. garn tilføj mocha chai debug supertest nodemon babel-cli babel-preset-node8 config --dev
4. garn tilføj ekspressmangoose
5. mkdir dist // når du kører garn build, gemmes prod-filer her
6. mkdir-test // mocha ser efter test her.
7. mkdir src; cd src; tryk på index.js &

Når du har kørt disse kommandoer, går du derefter til din package.json og opsætter dine scripts som dette:

"build": "babel src -d dist - kildekort"

Så de første script opsæt, hvad der sker, når du kører garn run build. Her bruger vi babel til at kompilere al koden i src-mappen og konvertere den til ES5-syntaks og gemme den i dist-mappen. I vores produktionsopsætning kører vores applikation fra denne mappe.

"serve": "NODE_ENV = produktionsnode dist / index.js",

Den anden scriptlinje starter serveren i produktionsmiljøet eller tilstanden ved at indstille miljøvariablen NODE_ENV til produktion. Dette er vigtigt, fordi det er visse kodelinjer, som du kun vil køre i produktionen, eller der er visse konfigurationer, som du kun vil gøre tilgængelig i produktionstilstand. Dette skal kun køres efter at have kørt garnkørsel. Bemærk, at vi ikke bruger Babel bare node, dette er fordi koden allerede er kompileret til en version, der knytter uden nogen specielle compilere som babel ved hjælp af build-kommandoen.

"dev": "DEBUG = server: debug NODE_ENV = udviklings nodemon src / index.js - exec babel-node"

Denne linje starter applikationen i udviklingsfunktion, og her bruger vi nodemon for at sikre, at node-serveren, når vi ændrer vores kode, er i stand til at genstarte og indlæse de nye ændringer. Vi opsætter også en miljøvariabel kaldet DEBUG, som vi indstiller til server: debug, dette er behovet af pakken Debug for at bestemme, om der skal vises konsollogger eller ikke, afhængigt af miljøet. Her vil vi kun vise logfiler, når vi kører i applikationen i debugtilstand. Jeg vil forklare, hvordan vi gør det, mens vi fortsætter. Vi indstiller også scriptet til at udføres ved hjælp af babel-node, dette giver os mulighed for at bruge den nyeste javascript-syntaks ES6 +.

"test": "DEBUG = server: debug NODE_ENV = test mokka - kræve babel-core / register - reporter spec - afslutte tests /"

Til sidst opsatte vi scriptet til at køre test. Her er vores miljø indstillet til at teste, vi indstiller det også til at køre vores test vha. Mokka. Vi sørger for, at vi instruerer mokka til babel-core / register, dette er vigtigt for, at vores ES6 + -kodesyntax skal køre, uden det vil mokka ikke gøre det. Vi satte også reporterflagget til at bruge spec, der definerer, hvordan vores test vil se ud i vores konsol. Vi bruger også exit-flaget, der kommandoer mokka for at stoppe dens proces, når alle testene er udført, ellers vil det hænge. Sidst fortæller vi Mocha at kigge efter test i testmappen.

Lad os indstille vores miljøer ved hjælp af Config

Husk, at vi har tre miljøer, som vores applikation kører i, og at hver vil have sine egne variabler, lad os opsætte hvert enkelt af dem, som vil blive brugt af pakkekonfigurationen. Dette er igen vigtigt, fordi det hjælper med at sikre, at vi konfigurerer vores server til at bruge visse indstillinger afhængigt af miljøet. For eksempel kan vi konfigurere vores server til at bruge udviklingsdatabasen, når vi kører vores server under udvikling, og produktionsdatabasen, når den er i produktionstilstand.

For at opsætte vores konfigurationsfiler skal du oprette en mappe kaldet configs og oprette tre filer, nemlig: udvikling.json, test.json og produktion.json (det er vigtigt, at du navngiver disse filer de samme navne, som din NODE_ENV-miljøvariabel har i hver af scripts i pacakge.json). Hver fil skal indeholde et JSON-objekt med de nøgler / værdipar, du vil bruge. Jeg bruger navnet, databasen og porten som mine nøgler.

// configs / udvikling.json
{
"name": "Serverudvikling",
"database": "mongodb: // localhost: 27017 / udvikling",
"port": 3000
}
// configs / test.json
{
"name": "Server Test",
"database": "mongodb: // localhost: 27017 / test",
"port": 3100
}
// configs / produktion.json
{
"name": "Serverproduktion",
"database": "mongodb: // localhost: 27017 / produktion",
"port": 3000
}

Test af miljøerne

Lad os nu se, at vores miljøer fungerer i overensstemmelse hermed. For at gøre dette vil vi oprette en express js-server i index.js med følgende kode.

Udviklingstilstand

På den første linje konfigurerer jeg den importerede debugfunktion til kun at vise dens log, når DEBUG-miljøvariablen er lig med 'server: debug'. Bruger også config.get () for at hente nøglens værdi fra de JSON-filer, vi opsatte i konfigurationsmappen. Vejkonfigurationen fungerer ved kun at indlæse den relevante JSON-fil, hvis navn matcher NODE_ENV's værdi.

Lad os nu teste, at vores server kører, og den gør det i det rigtige miljø, afhængigt af den kommando, vi bruger til at starte den. Her tester vi, at det kører udviklingsmiljøet ved hjælp af følgende kommando.

garn run dev

Du kan se, at vores server kører på det passende port, der er angivet i udviklingen.json-filen i mappen configs, og at det kører serverudviklingstilstand.

Test mode

Dernæst tester vi, at vores serverkørsel er i stand til at køre i testtilstand. Men i modsætning til de andre tilstande, der netop starter serveren, vil her også køre test ved hjælp af Mokka.

garnkørestest

Bemærk, at der siges, at 0 passerer. Hvorfor det? Det er okay, det betyder, at Mocha fungerer, men bare ikke fandt nogen test, og at vi kører i testmiljøet. Så vi kan derefter skrive test for, at Mokka kører. Vores første test vil bare kontrollere, at serveren kører på den port, der er angivet i den respektive JSON-konfigurationsfil, der bruges.

I koden ovenfor importerer vi forventningsmetode fra chai, denne metode giver os mulighed for at komme med påstande om serveren. I dette tilfælde vil vi teste, at den port, serveren kører på, er den samme som den, der blev brugt i test.json-filen i konfigurationsmappen. Vi pakker vores test ind i beskrevet funktion (tager navnet og callback-funktionen), som lige bruges til at gruppere lignende test. Den egentlige test er i 'it'-funktionen (tager også beskrivelse og tilbagekald). Testen lyder som almindeligt engelsk: forventer, at server.port skal svare til portnummeret i den aktuelle miljøkonfigurationsfil.

Efter denne kørsel af test af garnkørsel, og du kan se, at serveren kører i testtilstand, og at testen passerer. Hvis du ændrer portnummeret i metoden app.listen () i index.js og kører testene igen, ser du det mislykkes, og du vil straks vide, at noget er galt.

Produktionstilstand

Det sidste miljø, vi skal teste, at det fungerer, er produktionsmiljøet, men inden vi kører garnkørsel, skal vi først køre garnkøringsopbygning. Tabellen fortæller om at kompilere vores kode i ES5-syntaks og overføre de resulterende filer til mappen dist.

garn run build

Efter at have kørt garnekøringsopbygning, ser du, at dist-mappen har nye filer. Disse filer genereres, så du ikke bør foretage nogen ændringer i dem. Hvis du foretager ændringer i din kode, skal du bare regenerere dem ved hjælp af den samme kommando. På dette tidspunkt kan du nu køre garnkørsel.

garn køre tjene

Bemærk, at der ikke er nogen konsoloutput, der viser, hvilken port serveren kører på, dette skyldes, at i server-scriptet har vi ikke angivet DEBUG = server: debug-årsag, vi ikke ønsker at vise logfiler, når vi kører applikationen i produktionstilstand. Reglen er ikke, at du aldrig skal vise logfiler i produktionstilstand, især fejllogfiler, da de kan indeholde følsomme oplysninger. Men da det er nødvendigt at vide, hvilken port, serveren kører på, kan du tilføje denne linje:

console.log (`server kører på port $ {config.get ('port')} og i $ {config.get ('navn')} tilstand ');

Stop serveren ved hjælp af ctrl + d run garn run build og kør derefter garn run serve og du vil se følgende meddelelse.

Konklusion

Så for denne del af selvstudiet har vi dækket hvad TDD er, hvordan det kan hjælpe dig med at foretage ændringer i din kode med tillid og undgå de pinlige øjeblikke. Vi har også dækket, hvordan du konfigurerer dit projekt med de nødvendige pakker og også dækket, hvordan du opsætter tre miljøer, hvor din server kan køre i. I den næste af tutorial vil jeg dække, hvordan du nu skriver dine MongoDB-skemaer og server-API'er ved hjælp af TDD med SuperTest og Chai.

Koden til denne tutorial findes her: https://github.com/makayi/express-tdd-tutorial

Tak for læsning og glad kodning.

OPDATERING: del to er ude