Chrono MockFalšování data v aplikaci Electron
Vyhledejte si to a každá odpověď je o změně vlastního kódu - mockování objektu
Date, falešné časovače vašeho testovacího frameworku. Nic z toho nepomůže,
když máte hotovou aplikaci. Tohle spouští aplikaci, kterou už máte.
Proč se k ní injektáž nedostane
Tento režim existuje kvůli konkrétnímu selhání. Pomodoro časovač postavený na Electronu byl
spuštěn v sezení x60 a jeho odpočet se vůbec nepohnul. Rozebrání balíčku aplikace
ukázalo dva nezávislé důvody a ani jeden neměl řešení na nativní straně:
- Odpočet nečetl hodiny. Byl to čítač zvyšovaný funkcí
setInterval, běžící ve Web Workeru. Nebylo co zachytit, protože aplikace se nikdy neptala, kolik je hodin. - Tento worker žije v izolovaném procesu rendereru, tedy přesně na místě, kam se knihovna vložená zvenčí nedostane.
Mechanismus na straně Windows tu tedy nepomůže a řešením je místo toho mluvit s vlastním JavaScriptovým enginem aplikace.
Co se děje místo toho
Aplikace se spustí s ladicím portem a čistým jednorázovým profilem a její vlastní časová API se
přepnou na hodiny sezení přes protokol DevTools - Date.now, konstruktor
new Date(), performance.now, setTimeout a
setInterval.
Přepsání se nainstaluje do každého kontextu, který aplikace otevře, včetně jejích Web Workerů - tam časovač obvykle nakonec žije, a je to jediné místo, kam nativní injektáž nikdy nemohla dosáhnout.
Na tom, jak ho ovládáte, se nic nemění. Stejný příkaz, stejné okno, stejný panel sezení se dvěma hodinami a verdiktem.
# Stejný příkaz jako pro nativní aplikaci - režim se pozná sám chrono run "%LOCALAPPDATA%\Programs\your-app\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60
Dvě omezení, která stojí za to znát předem
Spuštění je invazivní a záměrně o tom mluví nahlas.
Aplikace se spustí s otevřeným portem vzdáleného ladění a novým, izolovaným profilem v
%TEMP% - neběží na vašem skutečném profilu a není to kopie, která už sedí v oznamovací
oblasti. Profil se po skončení sezení smaže, a pokud to nešlo, souhrn sezení to řekne, místo aby
ho tiše nechal za sebou.
Předání vlastního --user-data-dir nebo --remote-debugging-port se
odmítne, ne přepíše, protože zjevná nehoda - namířit sezení na váš skutečný profil prohlížeče -
není něco, co stojí za to povolit.
Stránky čtou časové pásmo sezení.
Každá stránka a každý worker se přepne na časové
pásmo sezení, pevný posun bez letního času, a kontroluje posun, který čte, takže
stránka, která přečetla jiné pásmo, je nahlášena. Dvě omezení: Intl toto pásmo
pojmenuje posunem jako GMT+02:00, ne městem, a hlavní proces aplikace Electron
spouští JavaScript v Node, kam sezení nedosáhne, takže si ponechává skutečné hodiny - zpráva
to říká.
Ještě jedna věc, která lidi překvapuje: interval už naplánovaný si ponechá svou starou
rychlost, když uprostřed sezení změníte rychlost. Date.now,
new Date() a performance.now reagují okamžitě, běžící
setInterval ne, a sezení na to upozorní, místo aby vás nechalo dojít k závěru, že
změna nic neudělala.
Jak dobře je otestován
Experimentální, a toto slovo tu má definovaný význam: funguje na cílech, proti kterým vznikl, nebyl široce testován a vestavěný audit je váš zdroj pravdy, ne tato stránka. Byl ověřen ručně, ne automatickou sadou, na skutečné aplikaci Electron na 64bitových Windows.
Pokrytí se hlásí po kontextech JavaScriptu, ne po procesech, protože to je jednotka, která tu existuje. Aplikace, která nečinně stojí a nikdy se nezeptá na čas, upřímně vyústí v neurčeno - nečetla hodiny, takže nelze nic tvrdit o tom, zda by viděla ty správné. Co verdikty znamenají →