Neexistuje žádné výchozí nastavené pořadí toho, jak Mocha načítá testovací soubory.
Když Mocha a> skenuje adresář k nalezení souborů v něm používá fs.readdirSync
. Toto volání je obal kolem readdir(3)
, která sama o sobě nezaručuje pořádek. Nyní, kvůli implementačnímu vtipu
výstup fs.readdir
a fs.readdirSync
je řazena na Linuxu (a pravděpodobně na systémech POSIX obecně), ale ne na Windows . Navíc je možné, že tříděné chování na Linuxu by mohlo být nakonec odstraněno, protože dokumentace říká fs.readdir
je pouze readdir(3)
a ten nezaručuje pořádek. Existuje dobrý argument, že chování pozorované na Linuxu je chyba (viz problém, na který jsem odkazoval výše).
Všimněte si, že existuje --sort
možnost, která bude třídit soubory poté, co je Mocha najde. Ale to je ve výchozím nastavení vypnuto.
Chování, které pozorujete, lze vysvětlit nejen příkazem načítání, ale také příkazem provedení . Zde je to, co se stane:
-
Mocha načte testovací soubory a spustí je. Takže vše, co je na nejvyšší úrovni vašeho souboru, se spustí okamžitě . To znamená, že kód v
test_helper.js
provede hned. Každé volánípopsat
okamžitě provede zpětné volání. Nicméně volá nato
zaznamenejte test pro pozdější provedení. Mocha objevuje vaše testy při provádění tohoto, ale nikoli provádění je hned. -
Jakmile jsou všechny soubory spuštěny, Mocha spustí testy. Do této doby kód v
test_helper.js
již byl spuštěn a váš test těží z připojení, které vytvořil.
Důležité upozornění Připojení k databázi je asynchronní operace a v současné době neexistuje nic, co by zaručovalo, že asynchronní operace v test_helper.js
bude dokončena před zahájením zkoušek. Že to teď funguje dobře, je jen štěstí.
Kdybych to byl já, dal bych vytvoření připojení do globálního asynchronního před
háček. (globální před
háček, který se objeví v libovolném testovacím souboru, bude proveden před jakýmkoliv testem, i testy, které se objeví v jiných souborech. ) Nebo bych použil --delay
a explicitně zavolejte run()
ke spuštění sady poté, co je zaručeno navázání připojení.