Vývoj zameraný na test - Strana 2 - Nemecké fórum Python
Od roku 2002 diskusie o programovacom jazyku Python
Testom riadený vývoj
Áno, možno by sa testy mali písať pri rozširovaní programu. Zdá sa, že je to rozumný spôsob vymedzenia, či sa testovanie oplatí.
V čom vidíte výhody py-testu alebo nosu oproti unittestu?
Poznáte niekto knihu Test Driven Development od Kenta Becka?
Ahoj, to je dobrá legitímna otázka.
Vidím to ako BlackJack a Eydu.
Pokrytie spojené s jednotkovými testami by malo byť pre vás ako programátora primárne nepríjemné Schudnite a zistite, či ste pokryli všetky prípady, ktoré potrebujete (ktoré považujete za dôležité). Pri veľmi veľkých aplikáciách často zabúdate na písanie testov jednotiek pre dôležité oblasti vášho softvéru, pretože sa stáva rozsiahlym, zložitým a neprehľadným [1].
Pokrytie by vás malo odbremeniť od identifikácie oblastí, ktoré ešte neboli pokryté jednotkovými testami [2]. Potom môžete pomocou vygenerovanej správy rozhodnúť, ktoré veci podľa vášho názoru musia byť pokryté a ktoré sú pre vás zanedbateľné. Zanedbateľnými vecami môžu byť napríklad skutočné banálne funkcie, ktoré sa predtým nezmenia a „vždy“ fungujú. - Ale ako už BlackJack správne naznačil, diabol je v detailoch. Často sú to práve tie veci, pri ktorých si myslíte, že „nemusíte zapadnúť“ a sú tam skryté chyby. Preto sa zvyčajne snažím (v závislosti od zložitosti softvéru) dosiahnuť 100% pokrytie.
[1]: A jednotkové testy sa väčšinou nepíšu paralelne so skutočným softvérom, ale oveľa neskôr = týždne alebo dokonca mesiace potom. Je to tak, že sa použije vývoj založený na testoch, kde sa najskôr zapíšu jednotkové testy a potom sa implementujú príslušné veci.
[2]: Takéto oblasti nie sú iba vo funkcii, ale predstavujú celý priestor modulu: Inými slovami, pokrytie vám zobrazí funkcie, pre ktoré neexistuje vôbec žiadny test jednotky. Napríklad, ak mám modul „foobar“, existuje „foo“ a „bar“ a napísal som iba test jednotky pre „foo“, následné pokrytie mi ukazuje, že „ panel '' nebol vykonaný (= testovaný) testovacím modulom jednotky.
Otázka vo vašom príklade „prístup k databáze a zásuvkám“ je, čo presne robí váš softvér? Pokiaľ váš softvér používa iba komponenty (ktoré sami nepíšete), nemusíte ich ani testovať! Nie je vašou úlohou pokryť knižnice tretích strán testami jednotky. Z tohto dôvodu žiada, aby ste napísali Mocksovi.
Predpokladajme, že máte funkciu alebo triedu, ktorá pristupuje k soketom prostredníctvom `soketu` a podľa výsledkov vykoná určité akcie alebo zmení stavy. Teraz nastáva problém, že ak ho použijete na prístup k externému $ SERVERU, ktorý musí vždy vrátiť určité údaje. V takom prípade abstrahujete `socket` a očakávané údaje od $ SERVERU do tej miery, aby vaša funkcia fungovala rovnako, ako keby ste skutočne použili` socket` s $ SERVER.
Konkrétne to znamená, že máte potrebné Prepisovacie rozhrania `soketu`, ktoré sa prestanú pripájať k $ SERVERu, iba vrátia dáta, ktoré očakávate od skutočného $ SERVERU. Celej veci potom treba prisľúbiť falošnú figurínu - figurínu, ktorú pripíšete svojej funkcii. Túto figurínu musíte samozrejme znova vytvoriť, aby chybové kódy/výnimky, ktoré očakávate, boli vyhodené ako v prípade pôvodnej.
A tam sa to začína komplikovať. Téma naozaj nie je úplne triviálna a môžete rýchlo dosiahnuť hranice uskutočniteľnosti (= proporcionalita). Nie nadarmo sa môže písanie testovacieho prostredia rýchlo stať rozsiahlejším a zložitejším ako testované prostredie. Tu musíte zvážiť medzi výhodami a proporcionalitou v jednotlivých prípadoch.
Mali by ste tiež zvážiť, či sa softvér používa v prostredí dôležitom pre bezpečnosť. IMO by sa tam oblasti dôležité z hľadiska bezpečnosti nemali vôbec testovať s falošnými údajmi, ale malo by sa vytvoriť skutočné existujúce testovacie prostredie špeciálne na to určené.
Čo je stále zaujímavé v súvislosti s jednotkovými testami, ktoré pokrývajú 100% všetkého, je skutočnosť, že jednotkové testy tiež predstavujú takpovediac špecifikáciu. Zadáte (abstraktne) celé rozhrania do najmenších detailov; aj keď iba čitateľný pre programátora.
V tejto súvislosti by bolo zaujímavé, keby existovali programy, ktoré by z nej vygenerovali aj špecifikáciu v čitateľnej podobe. a vytvoríte program, ktorý z neho vytvorí špecifikáciu
Znie to komicky, ale je to myslené vážne. V sklade Ruby existujú (izolované) úvahy v tomto smere. Existuje aj balíček na testovanie jednotiek, ktorý nehovorí o písaní testov jednotiek, ale o písaní špecifikácií - ok, žiadne prasa nevie čítať, okrem tých, ktorí napísali „špecifikácie“ alebo Ruby nerds