Hirdetés

Keresés

Új hozzászólás Aktív témák

  • Ezekiell

    veterán

    válasz p76 #14487 üzenetére

    Hát mi TDD-ztünk anno kb egy évet egy nagy projekten, több tíz fős fejlesztőcsapattal. Lehet csinálni, és jó cucc, de még egyszer nem csinálnám magamtól, nem a kedvenc metodológiám.

    Az előnyeit mindenki ismeri, google is segít, gyakorlatban viszont:
    - ha meglevő projekten kell TDDzni, akkor garantálnan refaktorálni kell egy raklap dolgot, mert a TDDhez olyan architektúra kell minden szinten, ami azt támogatja
    - emiatt lassú a TDD régi prohjekten, újon is eleinte az, utána már jobb a helyzet
    - mindenkinek TDDzni kell, elég 1 service pl, amit nem TDD-vel írtak, és van benne valami antipattern, és máris bukta - "felesleges" refactor, ami eszi az időt
    - irtó sok teszt lesz, karban kell őket tartani, az nem kicsi effort (ugyanakkor persze ez előny is lehet)
    - teljes gondolkodásmód-váltás kell, nem csak dev szinten, de feljebb is.

  • Drizzt

    nagyúr

    válasz p76 #14487 üzenetére

    Egyes subfeature-ekre volt mar ra pelda. Eleg jo volt a helyzet, mert aki csinalta a requirementet, ugy csinalta meg, hogy a teszt szinte copy paste volt belole. Csinalnek ilyet gyakrabban. De azert sajnos elegge gyakori volt anno, hogy a kodot mar irni kellett a requirement rogzitese elott. Ugy meg nehez a tdd. Mostani munkahelyen a hozzaallas pedig test in production. De ettol meg szerencsere az egyes embereknek nincs megtiltva, hogy teszteket irjanak, ha ugy latjak jonak. Elegge veszelyesnek tartom ezt a hozzaallast, megis valahogy mukodik. Jelentos reszben valoszinuleg azert, mert a fejlesztokben belulrol van igeny a kritikus reszek automata tesztelesere. Meg az is igaz, hogy kb. 4 ev a legkisebb tapasztalatu fejleszto, az atlag 15-20 korul mozog. Szoval megiscsak van teszt, de fentrol nem az az uzenet, hogy legyen.

Új hozzászólás Aktív témák