EGGH: Ahoj, toto forum je o server-side javascripte, na svoj request skus [ client side scripts (JavaScript) ]

kazdopadne to co chces urobit je viacmenej blbost, niektore prehliadace nativne blokuju window.open , lebo je to user hijack/spam metoda.
Nepotrebujes otvorit viac ako prave 1 okno, urobit prave 1 redirect adt. ak ano, mas to zrejme spatne premyslene.

Ahoj, snad jsem tu správně. Pokouším se vytvořit odkaz, na který když kliknu, tak se mi v prohlížeči otevře více oken s více stránkami. Např. když kliknu na odkaz, tak se mi otevře stránka seznam.cz, google.com, ebay.com, aukro.cz atd. Našel jsem na návod tady ale vždy se mi otevřou max. 2 linky i když jich tam mám 15 - prohlížeč opera. V IE se otevře jen první. V čem je chyba?

ve výsledku to tedy pak vypadá, že jsou balíky duplicitní (a určitě jsou), ale častokrát jeden balíček potřebuje nějaký jiný v jedné verzi a druhý zase chce verzi úplně jinou

mam dotaz k npm: nainstaluju si nejaky packages (D3, Cube, ...) do ~/node_modules/ nacez v adresari package pustim npm install a nainstaluji se zavislosti do ~/node_modules/*/node_modules/. Proc? Mnozi se mi duplicitni baliky v ~/node_modules/*/node_modules/, muzu je proste kopirovat do ~/node_modules/ ?

Bohužel nad tím jsem zatím moc nepřemýšlel, jak modelovat tu socketovou komunikaci. Spíš se tak nějak spoléhám, že to namodeluji právě pomocí BDD specifikace, která bude schopna ověřit, že vše funguje jak má. Chci to celé psát hodně modulárně, takže počítám z využitím socket namespace docela extenzivně.

Asi jsem nepochopil, co myslíš tím spec up front a že to není zadarmo.

Jak jsem psal, plánuju to tak, že veškeré mocky/stuby se budou injectovat pouze pro unit testy. Jakmile bude potřeba projet integrační testy, tak se tyhle simulace vyhodí a bude to (aspoň doufám), komunikovat proti živému zdroji.

Docela velkou šanci také vidím v tom, že pro architekturu jsem zvolil ECS, takže vše bude dost na sobě nezavislé a bude se to dobře testovat. Testování DOM mě momentálně trápí skutečně nejmíň ze všeho. Jak jsem psal, UI nebude nijak extenzivní a rozsáhlé. Většina bude o backendu, který se naštěstí dobře testuje.

AREX: Kdybys mel napady jak to vyresit, tak dej vedet -- jak vyresit realtime API / jak popsat message-based workflow resime uz nejakou dobu a furt nas nenapada nic dostatecne dobreho :/

AREX: Na to BDD jenom pozor ze to je vlastne dost narocny spec up front. Nic proti tomu, jenom ze to neni zadarmo (jako nci).

AREX: My projeli ruzna komba zombie/phantomjs/par jinych bazmeku, nicmene ve vsech ten server pod tim vzdycky bezel. IMHO to na *integracni* testy je potreba, jinak testujes v podstate jenom jednotkove...

Nejvetsi problem techhle testu je stejne 1) fakt ze DOM je API na coz neni frontend uplne stavenej a je potreba, aby s tim byli vsichi srozumeni 2) rychlost.

AREX: To je v pohodě dost často se řiká mock všemu :)

MARYO: Jo, máš pravdu, stuby budou lepší, trochu jsem poplet terminologii :)

AREX: Sice jsem to ještě nepoužil, ale až budu dělat příště REST API, určitě to vyzkouším, každej to chválil. Tohleto oddělení jsme dřív řešili tak, že jsme použili na straně klienta driver s testovacíma datama v local storage.

Ten socket.io už je trochu specifičtější problém no a žádný udělátko co by ti udělalo server na to asi nebude, nemám s tim moc zkušenost... Ale vzhledem k tomu, že akci může vyvolat i server, tak by se to asi blbě testovalo :)

Takže bych řekl, že nejlepší bude stubnout metody socket.io. V tom by mohl pomoct Sinon nebo Jasmine. Socket.io je vlastně pub-sub. Takže hned ten první a pár dalších příkladů.

Sinon.JS - Documentation
http://sinonjs.org/docs/#stubs

MARYO: Akorát teď koukám, že to stejně nebudu moct tolik využít. Chceme totiž využívat socket.io pro největší část komunikace. Apiary vypadá, že je pořád stavěná na bázi request / response, což u socketů není.

MARYO: Díky, to vypadá velice zajímavě, nevěděl jsem o tom.

Screencast apiary demo—by apiary.io
http://docs.screencast.apiary.io/

AREX: Aha, pochopil jsem to špatně. Namockovat server je určitě dobrá myšlenka.
http://apiary.io/ znáš?

MARYO: No jelikož uživatelské rozhraní bude spíš jednoduší, tak testy UI mě momentálně tolik netrápí. Tedy ani Cucumber bych do toho zatím tolik nemotal, ale časem na něj taky dojde řada počítám.

Nicméně tak nějak se mi líbí ta představa, že klient nebude závislý na serverové implementaci. Chtěl bych totiž celkové workflow nastavit tak, že se napíše specifikace v BDD stylu pro server. Pak zatímco jeden developer bude bouchat serverovou implementaci podle toho, tak další člověk si vezme tu specifikaci a pomocí mocku bude vyvíjet klienta aniž by musel čekat, až bude implementace serveru připravena.

Z mojí zkušenosti vím, že moc dobře nefunguje, když vývojáři serveru musejí být s implementací napřed a pak při chybách se k tomu vracet a dělat fixy. Navíc počítám, že mocky by se psali do separatního souboru, takže jakmile by server měl svojí implementaci, mocky by se odstavili a testy by proběhly proti tomu. Nahlášené bugy serveru se pak budou fixovat a klientský vývojář si zase zapne mocky a může pokračovat nerušeně dál.

AREX: Já bych se snažil naopak nemockovat dokud to jde. Živej server asi ne, ale prostě nějaká testovací instance s testovacíma datama. Pak se na ty testy můžeš víc spolehnout. Klidně to pod tim fantomem spouštět můžeš (ale pokud to nemá žádnej grafickej výstup, pak se budou testy blbě debugovat, v seleniu vidíš, jak si to pěkně kliká). Jako commit hook si to můžeš nastavit taky, jen s tim bude ňáká práce to všechno nastavit. Commitneš, nahrajou se testovací data, spustěj testy a na konci to pošle report nebo se to prostě nedeployne na stage serveru když to neprojde.

Na psaní těch testů bych použil něco jako CUCUMBER. Přijde mi to na to dělaný.

Zdravím. Když už jste tu nakousli TDD/BDD ... Zajímalo by mne, jakým způsobem preferujete psát testy klientské strany. Mám NodeJS server, pro něj píšu separatní testy. Přijde mi tedy trochu zbytečný, aby klientské testy běhaly proti živému serveru. Navíc se mi líbí myšlenka, že můžu PhantomJS pověsit jako git pre-commit hook a nechat proběhnout testy. Jakmile by to bylo závislé na spuštěném serveru, bude to o kus obtížnější a déle to bude asi trvat.

Na druhou stranu psát k vlastním testům ještě jednotlivé mocky/stuby je přeci jen trochu náročnější než rovnou přímé testy. A pak je to taky ten aspekt, že ani testy nedokážou pokrýt úplně vše a občas je potřeba si tu aplikaci taky zobrazit. Nejlépe ve spolupráci s LiveReload. To znamená, že server stejně bude muset být spuštěný.

Jaký na to máte názor ?

EDMAN_DORT: inak moj tip, ze najlepsie sa naucis s Node pracovat prostrednictvom TDD/BDD : )

http://visionmedia.github.io/mocha/ + potom nejake Assertions libs etc. daju sa v tom robit jak backend, tak frontend testy, unit aj end2end .

odporucam si to preluskat, hlavne od ludi zo https://github.com/saucelabs

3108: Jo diky, podivam se na to.