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.

EDMAN_DORT: ja som si ten nodejs spravil ked som zacinal, bolo vtedy tak, ze free 48hod, tak som to vyklikal a dostal som este reward nejakych ich $5 ich internej meny za kazdy splneny kurz. Inak co sa tyka topicov je to celkom v pohode, vysvetlia zaklady. za 500CZK mi to pride pre node JS prehnane, ale je tam napriklad Backbone, ktory je super spracovany.

Inak ak ta to zaujima trening zadar ma teraz aj 10gen

https://education.10gen.com/courses/10gen/M101JS/2013_August/about 4FREE

Zdravím, pouštím se pomalu do světa nodejs a baví mě to :D. Někoho by třeba mohlo zajímat, že na http://codeschool.com/ je celkem hezký úvodní online kurz. Stojí to cca 500 kč za měsíc, ale třeba pro mne je tam za ty peníze užitečného víc.

ALMAD: tazko povedat, pokial nevyroluju nejake specs, mozno ten nativny pristup k levelDB, mozno to bude vyhodne ako andorid backend pri vyuziti Google Cloud Messaging, mozno bude nizka latencia pri volani Google APIs aplikaciou.

Ked som videl ako idu extendovat appscripts a JS integracia do Google Docs, tak s nodeJS backendom tam vyrobis uz slusne ERP :D

Ale teraz vazne, neviem to osobne porovnat s nicim lebo som nezazil hostovanie nodejs appky, po blogoch si ludia chvalia to NodeJitsu, rovnako ako Joynet ci heroku.

Asi bude appengine iba alternativa, a mozno este k tomu aj drahsia.

3108: Vyhody proti jinym platformam?

Dnes boli na googleioePrague nejake rumours, ze AppEngine mozno ako dalsiu platformu bude supportovat NodeJS

ALMAD: jestli to chapu dobre, tak je na obojim, ale kod pise jen v nodu..

3108: ah. Takze si na klientu a ne v nodu ;)

ALMAD: uz je to vyriesene v podstate. otazka smerovala nato ci riesit veci cez objekty, alebo classy.

a spravne riesenie bolo cez classy, ze si spravis page object pattern, to znamena nasetujes do premennych hodnoty z DOMu, to znamena class names, ids, element names, selectors. nasledne vytvoris cez funckie, ktorymi volas dom a robis akcie na stranke, cize automatizujes preliezane, a nato nalepis mocha v spojeni bud s 'assert', 'should' alebo nieco dalsie. Klucovy ale bol ten page object pattern, a to ci ho implementovat cez object, alebo normalne class defintion a prototypovanie funkcii. kedze chces napriklad pri teste urobit n instancii a pustit ich zaroven (simulujes napriklad 3 browsery naraz, alebo 4 procesove vlakna. )

express nebol potrebny lebo v postate ziaden webserver nebol nevyhnutny.