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... :)
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! :)
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?
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.
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.
"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.
Show stopper
unit tesztek
Komplex
Elhiszem
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! :)
leírás, tutorial stb.?
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?
Nem tudok
Telepítsd a phpUnit-ot (vagy
Félreértettél
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.
"A test is not a unit test
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.
TDD-t nem is lehet máshogy
Yepp, szerintem sem annyira