ugrás a tartalomhoz

Pre-commit hook in Git: Running PHPUnit

inf3rno · 2012. Feb. 11. (Szo), 15.53
Kis hook a git-hez, ami committálás előtt lefuttatja a unit testeket. Ha a tesztek hibát jeleznek, akkor nem enged committálni.
 
1

Show stopper

janoszen · 2012. Feb. 12. (V), 23.00
Sztem elég erős show stopper, ha minden commitkor perceket kell várni. Ez inkább a CI szerver dolga.
2

unit tesztek

Bártházi András · 2012. Feb. 13. (H), 09.04
A unit tesztek egyik kívánalma, hogy gyorsak legyenek. Ha percekig tart a futtatásuk, akkor ott valami nem jó.
3

Komplex

janoszen · 2012. Feb. 14. (K), 09.59
Egyszerűen baromi komplex a szoftver. Na meg a PHPUnit sem a leggyorsabb.
4

Elhiszem

Bártházi András · 2012. Feb. 14. (K), 11.38
Ezek az _elvi_ unit teszt kívánalmak:
A test is not a unit test if:
  • It talks to the database
  • It communicates across the network
  • It touches the file system
  • It can't run at the same time as any of your other unit tests
  • You have to do special things to your environment (such as editing config files) to run it.
Ha nem csinál semmilyen I/O-t egy unit teszt, akkor baromi gyors tud lenni egy komplex szoftver esetében is. Ha csinál, akkor az "hivatalosan" már nem unit teszt, hanem integrációs teszt, vagy valami hasonló.

Ehhez az okfejtéshez hozzátenném, hogy komplex szoftverhez én még nem csináltam unit teszteket, csak olvastam ezekről. Ami azért nem ugyanaz... :)

Itt a teljes szöveg: http://www.artima.com/weblogs/viewpost.jsp?thread=126923

Amit esetleg érdemes lehet megcsinálni, hogy a gyorsan lefutó, alap dolgokat futtatni csak kommit előtt. Akkor van egy gyors visszajelzés ha valami nagy probléma van, de sokat nem is kell várni. Van egy continous testing című könyv, amiben egyenesek különben minden fájl mentéskor javasolják a unit tesztek lefuttatását. Na, az a kemény! :)
5

leírás, tutorial stb.?

H.Z. v2 · 2012. Feb. 14. (K), 11.46
Tudnátok adni olyan, magyar nyelvű oldalra mutató linke(ke)t, ahonnan korrekt infót kaphatnék a unit tesztek mibenlétéről?
Tegnap elkezdtem keresgélni, de csak nagyobb lett a káosz bennem e témát illetően.
Ugyanis egyre kevésbé értem, miért is jó, ha csak apróbb részeket tesztelek. És pl. a fenti értelmében, egy kifejezetten adatbázis műveletekre írt osztály esetében nem is lehet unit tesztet készíteni?
6

Nem tudok

Bártházi András · 2012. Feb. 14. (K), 12.43
Részemről nem tudok magyar forrásokat. Az adatbázis műveletekre a válasz a mockup, lásd https://www.google.hu/search?q=database+mockup+unit+testing.
7

Telepítsd a phpUnit-ot (vagy

inf3rno · 2012. Feb. 14. (K), 17.43
Telepítsd a phpUnit-ot (vagy egy másik teszt rendszert). A phpUnit-hoz van mockUnit és dbUnit. Simán lehet tesztelni vele az adatbázis műveleteket is. Én mondjuk régebben enélkül teszteltem simán csak annyival, hogy kézzel felvittem valamilyen adatot az adatbázisba, futtattam rá az SQL-t, és megnéztem, hogy az eredmény az e, amit vártam. Semmit bonyolult nincs ebben. A haszna annyi, hogy mondjuk egy 50 SQL-t használó projektnél kapásból 3 hibát felfedeztem olyan részeken, amiket nagyon ritkán használ csak a rendszer. A másik haszna megint csak annyi, hogyha módosítasz valamit, akkor a teszt futtatásakor látod, hogy van e hatással a rendszer többi részére, vagy sem. A TDD-nél meg a teszttel mondod meg, hogy milyen viselkedést szeretnél látni az adott metódusnál, ott először a tesztet írod meg, aztán az implementációt. Így biztosítva van, hogy minden úgy működik, ahogyan elvártad, és nem kell sosem azon agyalni, hogy vajon hol lehet a hiba a rendszerben, mert a tesztek azonnal mutatják. Én inkább könyveket ajánlanék cikkek helyett, a unit test témája akkora, hogy nehéz rövid cikkekben összefoglalni, hogy mit és hogyan. Majd ha már jobban elmélyültem a témában, és napi szinten használom, akkor lehet, hogy megpróbálkozok a cikkírással, addig viszont nem látom túl sok értelmét. Egyelőre a tesztek írása még elég döcögősen megy nekem is.
8

Félreértettél

H.Z. v2 · 2012. Feb. 14. (K), 18.17
Két külön nyűgöm van:
Az egyik, hogy egyre kevésbé értem, hogy mi az a unit teszt, mert minél több, a témával foglalkozó írást olvasok, annál több ellentmondást vélek felfedezni. (de ugye láttam már ELTÉ-s anyagban olyat, hogy a Python gyengén típusos nyelv... szóval a netes források sem túl megbízhatóak)
A másik, amit András idézett: "A test is not a unit test if: It talks to the database...". Erre jött a kérdésem, hogy akkor hogyan lehet tesztelni egy kifejezetten adatbázis műveletek elvégzésére létrehozott osztály egyes alkatrészeit? Hisz épp a lényeget nem tesztelem vele, vagy ha mégis, akkor az a "szabvány" szerint már nem unit teszt.

A TDD meg még ad egy plusz csavart a dologhoz, abba nem is másznék bele.
9

"A test is not a unit test

inf3rno · 2012. Feb. 14. (K), 20.18
"A test is not a unit test if: It talks to the database..."
Wikipedian azt írják, hogy a unit test az komponenseket tesztel, az integrity test meg modulokat. Ha az adatbázist egy modulnak tekintjük, akkor valóban nem unit test az, ami vele kommunikál.

Szóval ebben az esetben ott van a unit test határa, hogy a programod által gyártott SQL-t ellenőrzöd, hogy tényleg olyan e, mint amit vártál. Ennek általában nem sok értelme van, hacsak nem ORM-et fejlesztesz... :-) Ami meg már elküldi az SQL-t, meg választ vár, az meg integrációs teszt. Azt hiszem azért is érdemes ezeket elkülöníteni, mert ha egy-egy modult lecserélsz, vagy verziót változtatsz rajta, akkor elég csak annak a bizonyos modulnak az integrációs tesztjeit futtatnod ahhoz, hogy ellenőrizd, hogy minden helyesn működik e.
10

TDD-t nem is lehet máshogy

Joó Ádám · 2012. Feb. 14. (K), 23.30
TDD-t nem is lehet máshogy csinálni, mint minden módosításkor futtatni a teszteket.
11

Yepp, szerintem sem annyira

inf3rno · 2012. Feb. 15. (Sze), 02.33
Yepp, szerintem sem annyira "kemény" :-)