Unit testy su naviac proceduralne, vhodne na testovanie bezstavovych procedur. (Na OOP nevhodne) Komplexnejsie spravanie sa s tym komplikovane testuje, ze sa na to clovek radsej vykasle.
Osobne ich pouzivam presne na take procedury, kde viem, ze pre vstup A ma byt vystup B, uz mi to par krat zachranilo zadek.
Unit testy se samozřejmě s výhodou používají i na OOP, protože se jimi dá testovat i stavové chování objektů. Kdyby se daly testovat jen bezstavové metody, byly by takto omezené testy k ničemu.
V tomhle souhlasím. Jednotkové testy a OOP k sobě patří a součástí jednotkového testu běžně je uvedení objektu do nějakého požadovaného stavu a následně provolání jeho metod a kontrola vrácených hodnot a výsledného stavu.
Potíž je spíš v tom, přesně vědět, co má být ten požadovaný a cílový stav a jak se mají konkrétní metody chovat. Často to nikde popsané není a lidé to mají jen v hlavě – na rozdíl od požadavků vnějšího rozhraní, které spíš bývají někde napsané a schválené.
Ale pokial skutocne clovek pise OOP a nie nejaku parodiu na to, tak vztahy medzi objektami neumoznuju dobre pokryt spravanie unit testami. Vezmite si uz len taky polymorfizmus, (Objekt A dedi od objektu B, nechytajte ma na terminologii, na triedy sa nehram 
). Niekde v konfiguracii objektu C je malo dolezity objekt A. S objektom A sa spravi unit test. Unit test prejde. Ale zrazu nieco blbne na produkcii. To preto, lebo v konfiguracii je objekt B. Uviedol som najtrivialnejsi pripad. Ani rozne "mocky" nie su spasonosne riesenie, lebo nerataju so vsetkymi moznymi nastaveniami v produkcii. OOP vytvara velku sadu moznosti, lebo zapuzdruje vykonavany kod.
To se klidně může stát, ovšem problém není v OOP, ale v tom, že nemáš nikde přesně specifikované, jak se má který objekt/třída chovat – takže jednotkové testy střílíš od boku. Představ si, že bys měl proceduru s padesáti parametry, některé vstupní, některé výstupní, některé oboje a zdokumentované to budeš mít jen minimálně – přestože tam není žádné OOP, jednotkový test taky nenapíšeš – resp. nějaký napíšeš, ale bude k ničemu, protože nevíš, jak se to (na téhle úrovni) má chovat. Oproti tomu integrační/systémové testy napíšeš a budou ti užitečné, protože třeba implementuješ protokol podle nějakého RFC nebo máš závaznou specifikaci, kterou ti podepsal zákazník – na tom se dá stavět.
(případně nemáš vůbec nic a programuješ to jen na základě domněnek a výkřiků, které se k tobě dostaly po telefonu, ale tam už bych pak nemluvil o vývoji softwaru resp. softwarovém inženýrství)
BTW: dělal jsem i v týmu, kde se drželo 100% pokrytí jednotkovými testy a návrh i na úrovni tříd byl písemně zdokumentovaný a bylo možné psát dobré jednotkové testy – byla to příjemná práce a mělo to úroveň. Ale běžná praxe ve většině firem to rozhodně není – nemají na to. A dokud (pokud) je nedokopeš k tomu, aby bylo dobře specifikované chování na úrovni tříd, tak nemá smysl si nalhávat, že tě jednotkové testy spasí. Je lepší začít tím, co máš dané a dobře popsané – což bývá vnější rozhraní → integrační/systémové testy. A taky až si bude zákazník na něco stěžovat, tak to bude právě rozpor se specifikací vnějšího rozhraní – ovšem jestli si mezi třídami uvnitř předáváš takové hodnoty nebo makové je mu úplně jedno.
49 Odpovědí
7871 Zhlédnutí