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

• #11825 Peter Kiss őstag

  Új Válasz 2012-11-12 22:13:30 #11825

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Peter Kiss

  őstag

  Számomra itt a beszélgetés folyamán kicsit úgy tűnik, mintha két dologról lenne szó: az egyik, hogy megoldunk egy problémát, azt hogyan programozzuk le, a másik, hogy előbb megépítjük a környezetet, és azt hogyan programozzuk le. Nem tudom, lehet, hogy nekem tűnik így. Mindegy, tegyük túl magunkat a felhozott kódolási anti-pattern-eken:

  @Soak: Abban az esetben, ha van egy üzleti problémánk, akkor semmiféle képpen sem fogunk attól többet fejleszteni, mint amennyi szükséges. Vegyük azt, hogy egy teljesen új dologról van szó, nem kell régi vacakkal foglalkoznunk, és emellett van egy keretrendszer (ez lehet bármi, .NET, Zend Framework, mindegy), amiben dolgozunk. Tételezzük fel, hogy tiszta a megvalósítandó üzleti logika, gyakorlatilag csak fejlesztenünk kell. Hogyan érdemes ezt elkezdeni?

  Írunk teszteket, amelyek lefedik nagyvonalakban, amit szeretnénk kivitelezni, ilyen fázisban még a teszt is ocsmány lesz, mert csak körbelőjük, mit is szeretnénk. Ha ez megvan, megírjuk az első kódot, teszt, kódírás/refaktor/újabb teszt, innen már tudjuk, TDD.

  Ha így fejlesztünk, akkor észrevetjük, hogy az elején nagyon sokat kódolunk (leginkább a tesztek megírása miatt, nem az interface-ekre (vagy akár a mock-okra, stub-okra) gondolok, mert az relatíve kevés időt vesz igénybe), ellenben automatán tudunk mindent tesztelni (UI-t nehézkes ilyen szempontból, törekedni kell arra, hogy ott a lehető legkevesebb hiba fordulhasson elő). Mikor jó egy unit teszt?

  Ha azt és csakis azt teszteli, amit kell, gyorsan lefut, és egyértelmű a leírása. Ahhoz, hogy a teszt ilyen legyen az kell, hogy maga a tesztelendő kód is felvegye ezt a jelleget, normálisan megírt OO kód nélkül ez lehetetlen.
  Persze, a unit tesztek önmagukban kevesek, hiszen attól, hogy egy-egy rész jól működik, a big-picture még lehet, hogy sz.rt se ér, ehhez integrity test-ek kellenek.
  Mit látunk ezen a ponton?

  Összevetve egy nem TDD-s csapattal, sokkal több időt töltöttünk mindenféle kód (production + ami a teszthez kell [és a világos megoldáshoz!]) megírásával, viszont sosem kell amiatt aggódnunk, hogy nagy hibát vétenénk, ha kalapálunk valamit, segítenek a tesztek. Hibát keresni is sokkal gyorsabb lesz, hiszen rengeteg dolgot fejlesztési időben ki tudunk szűrni, illetve a kiadott verzióban is kevesebb lesz az utólagos hibák száma.

  Azt már említeni se merem, hogy léteznek olyan eszközök, amelyek kódolás alatt automatán futtatják a teszteket, így mindig up-to-date lehetsz (PHP-hoz nem tudom, van-e ilyen).

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