RSS Feed LinkedIn Google Plus

Kategória: Programozá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. TDD – hány tesztet írjak?

    2013. június 6. csütörtök

    Visszatérő kérdés a Test Driven Developement fejlesztés esetén: hány tesztet írjak, mikor lesz jó. Nagyon nehezen értettem meg, pedig sokszor mondták: a TDD nem tesztelési, hanem fejlesztési módszertan. Az Agile Hungary és a Teszt&Tea meetup közös rendezvényén Szabó Attila zseniális előadást tartott arról, hogy 2013-ban hogyan ne fejlesszünk TDD-ben, s végre megvilágosodtam. Először megfogalmazom, hogy mit szeretnék csinálni (teszt), majd azt, hogy hogyan (kód), s a végén fontos a refaktor. Ne legyen felesleges teszt (olyan teszt, aminek a megfogalmazása után nem lesz kód változás) és ne legyen teszteletlen kód. Ennyi a lényeg.


  3. JavaScript RegExp visualizer

    2013. március 4. hétfő

    A reguláris kifejezés valami olyan, amit legtöbbször csak write-only módban lehet kezelni: ha nem tetszik, az esetek nagy részében könnyebb újra megírni, mint kijavítani.  Néha azonban jól jönne apróbb javítást eszközölni, vagy csak átnézni, hogy valóban azt csinálja-e, amit akarunk, ebben nyújthat nagy segítséget a Regexper honlap.

    Vegyünk például egy egyszerű esetet: email címet szeretnénk validálni kliens oldalon. Rákeresünk a Google-ön, az első találat (nálam legalábbis) egy StackOverflow-os válasz elfogadva megoldásnak (ott a nagy zöld pipa), és 439-en szavaztak rá, tökéletes. A kód így néz ki: (more…)


  4. A kódunk legyen öndokumentált!

    2012. december 15. szombat

    Kérlek, mondd el röviden, mit csinál az alábbi CoffeeScript kód!

    uglyStep = (arr) ->
        res = []
        arr.forEach (a) ->
            count = 0
            arr.forEach (b) ->
                count += 1 if \
                    Math.abs(a.x - b.x) <= 1 and \
                    Math.abs(a.y - b.y) <= 1 and \
                    (a.x != b.x or a.y != b.y)
            res.push(a) if 2 <= count <= 3
        arr.forEach (a) ->
            for i in [-1..1]
                for j in [-1..1]
                    live1 = arr.some (cell) ->
                        (cell.x == a.x + i and cell.y == a.y + j)
                    live2 = res.some (cell) ->
                        (cell.x == a.x + i and cell.y == a.y + j)
                    unless live1 or live2
                        current = {x: a.x + i, y: a.y + j}
                        count = 0
                        arr.forEach (b) ->
                            count += 1 if \
                                Math.abs(current.x - b.x) <= 1 and \
                                Math.abs(current.y - b.y) <= 1
                        res.push(current) if count == 3
        res

    Ha a válaszban olyan szavak szerepelnek, hogy „végimenve”, „megnézzük”, „hogyha egyenlő”, az mutatja a problémát. A kódnak önmagában érthetőnek és világosnak, vagyis öndokumentált jellegűnek kell lennie. Viszont dokumentációban és a tesztekben azt írjuk le, hogy mit csinálunk, nem azt, hogy hogyan. (more…)


  5. Second Global Day of Coderetreat

    2012. december 8. szombat

    Hű, nagyon jó volt! A teszt vezérelt fejlesztés már rutinosan ment, így tudtunk a feladatra koncentrálni, és nagyon élveztem a páros programozást. :) Kódoltam C++-ban is (eleinte csak néztem, ahogy a társam kódol, de aztán fokozatosan felelevenedtek az emlékek). Jó partnereim voltak, és mivel minden egyes sessionban elölről kellet kezdeni a kód írást, nem mentem bele hitvitákba: ha a társam kötötte az ebet a karóhoz, ám legyen, egy sessiont kibírunk, és levonjuk belőle a tanulságot. (Igaz, az első sessionban én is egy rossz statégia mellett kardoskodtam.) (more…)


  6. Legacy Code Retreat Day

    2012. november 17. szombat

    Legacy kód az, amihez nincsenek tesztek.

    Ma volt a magyarországi első Legacy Code Retreat Day, melynek során a megörökölt – specifikáció és leírás nélküli, kissé hibásan működő, a spagetti elvet szem előtt tartva készült – kódot kellett először is megértenünk, majd javítanunk és újabb funkcionalitással ellátnunk. Az elmélet nagyon egyszerű:

    • a kód átláthatatlan és érthetetlen, nem is tudjuk mit csinál
    • először is megértjük – szükség esetén eközben készítünk megértési refaktorálásokat, amiket később visszavonunk (!)
    • generálunk egy end-to-end tesztet, hogy a jelenlegi funkcionalitást semmiképpen se rontsuk el
    • a kódot elkezdjük kijavítani, hogy karbantartható legyen, eközben a funkcionalitást egyre jobban unit tesztekkel fedjük le, mindezt megtámogatva a generált e2e teszttel
    • ahogy halad az idő, az open closed szemléletet igyekszünk érvényesíteni: a kódunk legyen nyitott a bővítésre, de zárt a módosításra, vagyis az új funkcionalitás megvalósítása esetén új dolgokat kelljen hozzáadni, ne a régit módosítani
    • és így tovább…

    Sajnálatosan azonban a jelenlevőknél legtöbb esetben működtek a régi reflexek: itt a kód, itt az elvárt módosítás, no gyorsan javítsuk ki, és kész. Ja, hogy nem biztos, hogy jó lett? Hogy a javítás esetleg egy másik részt elronthat… És mégis sok esetben inkább nekiálltunk hack-elni…

    Többünk tapasztalata szerint az elkészült tesztekkel exponenciálisan nőtt a fejlesztői magabiztosság, hiszen már tudtam mit csinál, és azt is tudtam, hogy ha változtatok és a tesztek jók, akkor rendben van.

    Számomra a nagy ötlet az volt, hogy az elején (rögzítve a random számokat) generáltunk egy elvárt input-output, ami az esetek túlnyomó részét lefedte, így ezt ellenőrző pontként felhasználva el tudtuk kezdeni egyáltalán fejleszthetővé és karbantarthatóvá tenni a kódot.

    Hallottam kollegákat áradozni a páros programozásról, nekem eddig egyáltalán nem voltak jó tapasztalataim e téren, és sajnos ez a nap sem hozott radikális fordulatot. Nem volt rossz, de ott volt az érzés, hogy egyedül lehet, hogy jobban haladtam volna.

    A helyszínt és az ételt-italt (beleértve az ebédet) az emarsys biztosította, az elején tartottak egy rövid bemutatkozást, és az iroda is nagyon szép volt. A web konferencián beszéltem még Merklik Lászlóval, náluk a TDD mindennapos gyakorlat, ezért is támogatták a rendezvényt, és örülnek, hogy vannak lelkes, szombatjukat is rászánó fejlesztők Magyarországon. Köszönet a szervezőknek (Devill és Athos)!


  7. Hogyan commitoljunk?

    2012. január 20. péntek

    Minden programozási nyelvnek megvan a maga általánosan elterjedt, elfogadott kódolási stílusa, amit illik betartani. Saját projektnél mindenki azt használ, amit akar, de ha szeretne becsatlakozni egy munkába, akkor kötelezően alkalmazkodni kell az ottani szokásokhoz, míg ha szeretné elfogadtatni a saját munkáját, célszerű ezeket figyelembe venni, hiszen a kollégák szeme is „rá van állva” bizonyos dolgokra. Például ha az i, j változók valamilyen objektumra mutatnak, az felrúgása a konvenciónak, hiszen ezeket ciklusváltozóként, de legalábbis nem negatív egész számként szoktuk használni. De ugyanilyen kérdés az elnevezés, hiszen egyes nyelvekben a camelCase, máshol az aláhúzással tagolt módszer az elterjedt.

    A Git-es világnak is megvannak a maga kvázi szabványai, amelyeket ugyanilyen jól teszünk, ha betartunk. Korábban én is írtam negatív jelenségekről, de való igaz, nagyobb hatása van, ha a kívánatos út is be van mutatva. Az alábbiakban Scott Chacon Pro Git könyvének ide vonatkozó fejezetét (6.2.1. fejezet, 94-95. oldal) és a és a Git forráskódjában megtalálható kvázi szabványnak tekintett Documentation/SubmittingPatches fájl tartalmát foglalnám össze. (more…)


  8. Verziókezelés…

    2011. december 28. szerda

    Git? SVN? Teljesen mindegy*.

    * ha nem értjük, mi az a verziókezelés. (more…)


  9. Git reset – hogy is van az?

    2011. december 12. hétfő

    A Git Pro könyvből én is hiányoltam a reset parancs bemutatását. Scott Chacon egy külön bejegyzésben kifejtette, amit a könyv írásakor még nem értett. Színes ábrákkal, részletesen mondja el, úgyhogy az angolul kevésbbé tudók is megértik, nem fejtem ki magyarul. (Nem sok újat mondott, a mindennapi használatban én is erre jöttem rá, csak nekem nincsenek ábráim hozzá.) :) De nézzünk egy trükkös gyakorlati példát: hogyan történjen az A → B merge, ha a B változásait dobni akarjuk?

    Tegyük fel, hogy a fejlesztési időszakban (ETAP) van néhány hibajavítás az éles ágon, és rengeteg refaktor és fejlesztés a fejlesztési ágon, emiatt megegyezünk abban, hogy minden éles ág-beli javítást megcsinálunk a fejlesztési ágon is. Így ETAP végén a fejlesztési ág minden hibajavítást tartalmaz, viszont a szokásos fejlesztési ág → éles ág merge nagyon sok conflict-ot okozna. Hogyan tegyük „a fejlesztési ágat élessé”? (more…)


  10. Git-svn: ha nincs ló, jó az öszvér is

    2011. november 29. kedd

    A Git-ről nagyon jókat írnak, a munkahelyemen azonban SVN-t használunk. Hallottam a git-svn-ről, de nem volt valami bizalomgerjesztő ötlet, hogy két különböző szemléletű verziókezelő rendszert „összeolvasszunk”. Az SVN-t ráadásul megszoktam, megvoltak hozzá a kézreálló eszközök, ha másra váltok, ezeket bizonyosan elvesztem, újak után kell nézni. Meg kell tanulni az új parancsokat, stb. Macerás. Aztán mégis csak belevágtam, és egyáltalán nem bántam meg. Miért?

    (more…)