Der er ingen standard indstillet rækkefølge for, hvordan Mocha indlæser testfilerne.
Når Mocha scanner en mappe
for at finde filer i den, bruger den fs.readdirSync
. Dette opkald er en indpakning omkring readdir(3)
, hvilket ikke i sig selv garanterer orden. Nu, på grund af en implementeringsfejl
outputtet af fs.readdir og fs.readdirSync er sorteret på Linux (og sandsynligvis POSIX-systemer generelt), men ikke på Windows . Desuden er det muligt, at den sorterede adfærd på Linux i sidste ende kan blive fjernet, fordi dokumentationen siger fs.readdir er bare readdir(3) og sidstnævnte garanterer ikke orden. Der er et godt argument at fremføre for, at den adfærd, der observeres på Linux, er en fejl (se problemet, jeg linkede til ovenfor).
Bemærk, at der er en --sort mulighed, der vil sortere filer efter Mocha har fundet dem. Men dette er deaktiveret som standard.
Den adfærd, du observerer, kan ikke kun forklares ved indlæsningsordre, men ved udførelsesordre . Her er, hvad der sker:
-
Mocha indlæser testfilerne og udfører dem. Så alt, der er på det øverste niveau af din fil, udføres med det samme . Det betyder, at koden i
test_helper.jsudføres med det samme. Hvert opkald tilbeskrivudfører straks sit tilbagekald. Kalder dog tilitoptag testen til senere udførelse. Mokka opdager dine tests, mens du gør dette, men ikke udfører dem med det samme. -
Når alle filer er udført, begynder Mocha at køre testene. På dette tidspunkt er koden i
test_helper.jsallerede har kørt, og din test drager fordel af den forbindelse, den har skabt.
Større advarsel At oprette forbindelse til en database er en asynkron operation, og i øjeblikket er der intet, der garanterer, at den asynkrone operation i test_helper.js vil være gennemført, inden testene starter. At det fungerer fint lige nu er bare held.
Hvis dette var mig, ville jeg enten sætte forbindelsesoprettelse i en global asynkron før krog. (En global før hook, der optræder i en hvilken som helst testfil, vil blive udført før en hvilken som helst test, selv test, der vises i andre filer. ) Eller jeg ville bruge --forsinkelse
og kald eksplicit run() for at starte suiten, efter at forbindelsen er garanteret oprettet.