Tesztvezérelt fejlesztés - 2. oldal - A német Python fórum
2002 óta vita a Python programozási nyelvről
Tesztvezérelt fejlesztés
Igen, lehet, hogy a teszteket a program kibővítésekor kell megírni. Úgy tűnik, hogy ez ésszerű módszer annak meghatározására, hogy érdemes-e tesztelni.
Hol látja a py-teszt vagy az orr előnyeit az unittesttel szemben?
Ismeri valaki Kent Beck Test Driven Development című könyvét?
Helló, ez jó jogos kérdés.
Úgy látom, mint BlackJack és Eydu.
Az egységtesztekhez kapcsolódó lefedettségnek elsősorban az Ön számára, mint programozónak kell bosszantania Fogyjon le a munkából, hogy azonosítsa-e az összes szükséges esetet (amelyet fontosnak tart). Nagyon nagy alkalmazások esetén gyakran elfelejted megírni az egységteszteket a szoftver fontos területein, mert kiterjedté, összetetté és zavaróvá válik [1].
A lefedettségnek fel kell szabadítania Önt azon területek azonosításának munkájától, amelyekre még nem vonatkoztak az egységvizsgálatok [2]. Ezután a létrehozott jelentés alapján eldöntheti, hogy véleménye szerint mely dolgokat kell lefednie és melyek elhanyagolhatóak az Ön számára. Az elhanyagolható dolgok lehetnek például olyan triviális funkciók, amelyek korábban nem változtak és "mindig" működnek. - De ahogy a BlackJack már helyesen jelezte, az ördög benne van a részletekben. Gyakran éppen azok a dolgok, amelyekben úgy gondolja, hogy "nem kell beilleszkednie", és a hibák ott rejtőznek. Ezért általában (a szoftver összetettségétől függően) megpróbálom elérni a 100% -os lefedettséget.
[1]: Az egységteszteket legtöbbször nem a tényleges szoftverrel párhuzamosan írják, hanem sokkal később = hetek vagy akár hónapok utána. Ez az, hogy az egyik tesztvezérelt fejlesztést használ, ahol először az egység teszteket írják meg, majd végrehajtják a megfelelő dolgokat.
[2]: Az ilyen területek nem csak egy függvényen belül vannak, hanem a teljes modulteret képviselik: Más szavakkal, azokat a függvényeket, amelyekre egyáltalán nincs egységteszt, a lefedettség jeleníti meg. Például, ha van a "foobar" modul, ott van a "foo" és a "bar", és csak egy egység tesztet írtam a "foo" -ra, a későbbi lefedettség azt mutatja, hogy a " A "bar" elemet az egység tesztmodul nem hajtotta végre (= tesztelte).
A példádban szereplő "adatbázis és socket hozzáférés" kérdés az, hogy pontosan mit csinál a szoftvered? Ha a szoftvere csak az összetevőket használja (amelyeket nem Ön írt), akkor ezeket sem kell tesztelnie! Nem az a feladata, hogy külső tesztkönyvtárakat lefedjen az egység tesztjeivel. Ehhez kéri, hogy írjon Mocksnak.
Tegyük fel, hogy van olyan funkciója vagy osztálya, amely a `socket`-en keresztül fér hozzá az aljzatokhoz, és az eredményektől függően bizonyos műveleteket hajt végre vagy állapotokat változtat. Most jön az a probléma, hogy amikor egy külső $ SERVER elérésére használja, amelynek mindig vissza kell adnia bizonyos adatokat. Ebben az esetben elvonja a `socket`-et és a $ SERVER várható adatait, amennyiben a funkciója ugyanúgy működik, mintha a` socket`-et használta volna a $ SERVER-mel.
Pontosabban, ez azt jelenti, hogy megvan a szükséges A `socket` olyan felületeinek átírása, amelyek leállítják a kapcsolatot a $ SERVER-rel, csak visszaadják a valódi $ SERVER-től elvárt adatokat. Az egészet akkor ígérni kell egy próbának - egy dummynek -, amelyet a funkciójának tulajdonít. Természetesen újból létre kell hoznia ezt a próbabábut, hogy a várt hibakódok/kivétel ugyanúgy eldobódjanak, mint az eredeti.
És itt kezd bonyolódni. A téma valójában nem éppen triviális, és gyorsan elérheti a megvalósíthatóság határait (= arányosság). A tesztkörnyezet megírása nem hiába válhat gyorsan terjedelmesebbé és összetettebbé, mint a tesztelendő környezet. Itt eseti alapon mérlegelnie kell az ellátásokat és az arányosságot.
Fontolja meg azt is, hogy a szoftvert biztonság szempontjából releváns környezetben használják-e. Az IMO-ban a biztonság szempontjából releváns területeket egyáltalán nem szabad tesztelni, hanem létre kell hozni egy valódi, erre külön aludt tesztkörnyezetet.
Ami még mindig érdekes a 100% -ban mindent lefedő egységtesztek kapcsán, az a tény, hogy az egységtesztek is úgymond specifikációt jelentenek. A teljes felületeket a legapróbb részletekig (elvont módon) adja meg; még ha csak a programozó számára is olvasható.
Ebben az összefüggésben érdekes lenne, ha léteznének olyan programok, amelyek egy specifikációt is olvasható formában generálnának belőle. Eddig megkerülheted, ha minden tesztesethez olyan utasításokat írsz, amelyek pontosan (minden részletet) leírnak a tesztesetről és létrehoz egy programot, amely specifikációt hoz létre belőle
Viccesnek hangzik, de komolyan gondolják. A Ruby raktárban (elszigetelt) szempontok vannak ebben az irányban. Van olyan egység tesztelési csomag is, amely nem az egység tesztek írásáról, hanem a specifikációk megírásáról szól - Ok, egyetlen disznó sem tud olvasni, kivéve azokat, akik a "specifikációkat" vagy a Ruby majmokat írták