RSS Feed LinkedIn Google Plus

Címke: tesztelés

  1. Kontextus függő tesztelés

    2013. június 8. szombat

    Nagy Gáspár az Agilis tesztelésről tartott előadást a legutóbbi Agile Hungary meetupon, az egyik dián a kontextus függő tesztelési iskola hét alapelvét mutatta be:

    1. Bármilyen módszer értéke a kontextustól függ
    2. Egy adott kontextusban vannak jó módszerek, de nincsenek általános legjobb módszerek
    3. Az együtt dolgozó emberek képviselik a legnagyobb értéket bármilyen projektben
    4. Projekt részletek változnak ahogy az idő halad, sokszor előreláthatatlan irányokba
    5. A termék egy megoldás. Ha a problémát nem oldja meg, a termék nem lesz sikeres.
    6. A jó szoftver tesztelés egy kihívásokkal teli intellektuális folyamat
    7. A termék hatékony teszteléséhez mindig a megfelelő lépéseket tesszük a megfelelő időben. Ezeket az egész projekt alatt gyakorlott szakértelem és elemzés segítségével tudjuk fejleszteni

    További információkat a http://context-driven-testing.com/ oldalon lehet beszerezni.

    Az ötös pont nagyon tetszik, hasonló elhangzott a korábbi TechTalk-os prezentációban Christian Hassa előadásában: sokkal többször bukunk meg amiatt, mert a rossz problémát oldottunk meg, mint amiatt, hogy rossz megoldást adtunk a jó problémára.


  2. Kell-e a seed a randomhoz?

    2013. április 20. szombat

    Olvastam egy jó cikket a JavaScript-beli Math.random()-ról. Ha csupán (pszeudo)véletlen számokat szeretnénk, akkor tökéletes, számomra nagyon szimpatikus volt, hogy nem kell más nyelvekhez hasonlóan inicializálni. Ez teljesen feleslegesnek tűnt egészen a legutóbbi és egyben első magyarországi Leacy Coderetreat-ig, amikoris megörökölt, véletlenszerű működésre alapuló programot kellett helyrepofoznunk, karbantartanunk. Az első lépés természetesen a tesztek írása – no, de hogyan? Más programnyelvben dolgozó kollégáim könnyen megoldották a kérdést, hiszen beégetett seed-et használtak a teszt adatok generálásához (itt akadtak gondok, amikor különböző platformon más sorozatot adott ugyanaz a seed), nekünk, script nyelveseknek más utat kellett járnunk: legeneráltuk előre a random számokat, és mindig ebből dolgoztunk.

    A fent említett cikkben több megoldás is található, ha nem elsődleges szempont a sebesség, de szükségünk van előre tervezhető véletlenszerű értékekre, David Bau megoldása tökéletes választás lehet JavaScripthez. Hátránya, hogy a natív Math objektumot módosítja, előnye viszont hogy transzparens – teszthez bekapcsolhatjuk, éles környezetben pedig továbbra is az eredeti Math.random() állhat rendelkezésünkre.

    Remélem, sikerült felkeltenem az érdeklődésedet, s bár a következő (egyben Legacy) CodeRetreat-re nincs már több hely, ha feliratkozol a Meetup.com-on, értesülhetsz a további lehetőségekről.


  3. A nap mondása (tesztelés)

    2012. január 30. hétfő

    if everything else fails, just disable unit tests. works all the time

    @rhapsodhy


  4. Jasmine, Vows+should+sinon…

    2011. június 6. hétfő

    Hosszabb szünet után végre ismételten Budapest.js meetup-on voltam. :)

    Aba Péter ismertette, miben tér el a Jasmine a QUnit-tól. Vártam volna, hogy többet mond a BDD-ről (ez számomra ismeretlen terület még), mindemellett tetszett az előadása.

    Lackac a Vows + should.js + sinon.js hármast mutatta be. Számomra kicsit tömény volt, de nagyon tetszett, hogy a gyakorlatról beszélt. Illetve gyorstalpaló jelleggel bemutatta ezen eszközök használatát, mégis érezni lehetett, hogy mindez számára/számukra nem csupán elmélet; a tesztelés, a BDD nem öncélú, ahogyan a Node.js használata sem.


  5. Agilis? Nem agilis?

    2011. április 19. kedd

    Verhás Péter élesen fogalmaz az agilis módszertant alkalmazókkal szemben. El tudom hinni, hogy a tapasztalataira épít. Ha az agilis annyit jelent, hogy nem kell tervezni, nem kell tesztelni, akkor sokkal gyengébb minőségű kód lesz. A nagy projekteket, komolyabb függvénykönyvtárakat, keretrendszereket, publikus API-kat igenis meg kell tervezni, dobozokat kell rajzolni hozzá, és stabillá kell tenni. Azt írja:

    A tesztelés megint egy külön téma, de ott meg aztán végképp nagyon rossz a tapasztalatom. Akár waterfall, akár agilis: tesztelés az nem nagyon szokott lenni. De, ahogy a levélíró is érzékeli: waterfall fejlesztésnél azért inkább. Ahhoz a habitushoz közelebb áll a fegyelem, a teszteléshez pedig fegyelem kell.

    Érdekes, igaza van. Pedig éppen az agilis környezetben lenne szükség arra, hogy jól felépített és széles körű automatizált teszteket futtassunk.

    Nálunk mindenesetre határozottan jó lépés volt az agilis módszertanra való áttérés, így a dolgoknak menete lett, tervezés, tesztelés, fix határidők, stb. Sajnos néha jelentkezik a „írjunk kódot, gyorsan” hozzáállás, így még a dokumentáció is lemarad, nemhogy a tesztesetek írása.

    Összességében mégis azt tudom mondani, hogy jól megszervezett és koordinált módon az agilis módszertannal történő fejlesztés az ügyfél számára is jobb. Ehhez látni kell azt is, hogy ez a módszertan is eszköz, nem cél.


  6. jDoctest – Test interactive JavaScript examples

    2010. október 30. szombat

    Dokumentálni és tesztelni többféleképpen lehet. A Python-féle doctest nagyszerű ötlete az volt, hogy ezt a kettőt ötvözzük: a dokumentációban adjunk példákat a függvényeink működésére paraméterekkel és várt visszatérési értékekkel, majd ezeket használjuk fel tesztesetként. A jDoctest JavaScript alá adoptálja mindezt QUnit támogatással. Szerintem kreatív ötlet, bár komolyabb tesztek írására alkalmatlan. A honlapja áttekinthető, a példa kódok érthetőek.