Automatické testovanie a nástroje

Akým spôsobom zvyknete testovať svoje aplikácie? Využíva tu niekto TDD/BDD/ATDD...?
Prípadne poznáte nejaké zaujímavé stránky na túto tematiku?

Osobne sa mi páči napríklad toto: http://artofunittesting.com/
Paráda je na tom to, že to nekončí na nejakej prezentácii knihy alebo pri základných princípoch, ale Roy sa snaží vysvetliť pointu na reálnych príkladoch. Dokonca v ľudskej reči

Ak sa niekto zaujíma o TDD určite by si mal prečítať aj články o tom, prečo také metódy nemusia byť najlepšie (hlavné body sú aj na wikipedii).

Tak samozrejme, že to má svoje plusy aj mínusy, ale to platí o každom postupe. Bohužiaľ zatiaľ nikto neprišiel s ničím naozaj univerzálnym, čo by stačilo do bodky nasledovať a bol by perfektný výsledok. V prvom rade treba pochopiť princípy a ich odôvodnenie, lebo inak to dopadne horšie ako pri klasickom spôsobe programovania.
Čo odporúčaš ty? Aspoň mi to tak vyznelo, že k podobným metodikám nemáš najlepší vzťah...

Nemám nič proti unittestom, sám ich občas používam.

Užitočnejšie je ale asi naučiť sa programovať jednoducho a prehľadne (pretože vyrobiť kvalitný unittest môže byť príliš komplikované a prílišná dôvera v nie príliš kvalitné unittesty sa často nevypláca).

No jo, prehľadne a jednoducho treba programovať vždy, akurát nie vždy je to také jednoduché... Sú projekty, kde máš proste viacero vrstiev, moduly, asynchrónne spracovanie atď. Teraz si pôvodný vývojár nájde lepšiu prácu, odíde a miesto neho príde nový vývojár a treba urobiť zmeny v systéme. Pokiaľ nie sú dobre (alebo dokonca vôbec) napísané testy, ako si môže byť istý, že úpravami nepoškodil nejakú inú časť systému, ktorá s tým zdanlivo vôbec nesúvisela? Ručne testovať/debugovať každú funkcionalitu je proste neprípustné, ak nie nemožné. TDD (a podobné metodiky) sa práve tomuto snažia zabrániť, kedy ti stačí pozrieť testy a môžeš v kľude pracovať na systéme aj o 5 rokov neskôr bez toho, aby si musel debugovať každý riadok kódu alebo dlhé hodiny rozmýšľal, ako to vlastne majster myslel. Testy by mali mať dostatočne popisné názvy, takže by si nemal potrebovať test ani otvoriť a mal by si vidieť, ako by sa mal systém správať.

Najväčšie problémy pri xDD sú práve v tom, keď s tým ľudia ešte nemajú skúsenosti, začnú na tom makať a netestujú to a tak, ako by mali. Potom samozrejme testom nedôverujú, prestanú testy udržovať a skončia s vetou "to je ale blbosť".
Dobré videá má napríklad Roy Osherove alebo aj Miško Hevery (aspoň teda podľa mňa).

TDD nie je len o jednotkových testoch, sú v tom zahrnuté prakticky všetky typy (integračné, unit testy, ...). Podstata je v postupe práce a v inkrementálnom zlepšovaní kódu....

Automatizované testy nie sú samozrejme all-in-one solution na všetky problémy, ale sú imho vynikajúcim doplnkom na to, aby sa programátor mohol sústrediť na to, čo je skutočne dôležité (povedzme na implementovanie novej funkcie bez strachu, že pokazí niečo iné ako vedľajší produkt).

Akurát nechápem, prečo si zatiaľ zareagoval len ty... Keď som sa pýtal v inej téme, či by bol záujem aj o iné debaty ako klasicky (nezobrazuje sa mi správne html stránka), tak všetci hneď "heej, jasné, určite". Dôjde na lámanie chleba a všetci zrazu ako mŕtve chrobáky Neviem, možno iná tematika by tu bola vhodnejšia?

Nedávno som portoval jednu knižnicu a robil alternatívny server pre nejakú aplikáciu. Obidva tie projekty mali unittesty a napriek tomu, že mi všetky testy s mojimi verziami prešli bez najmenších problémov, moje verzie v reálnom používaní nefungovali. Takže som aj tak musel študovať zdrojový kód a keby tie dva projekty boli urobené prehľadnejšie, trvalo by mi to výrazne kratšie.

Inak chyby sú aj v projektoch pokrytých 100% unittestami, takže spoliehať sa na ne nie je rozumné (a keďže zvyčajne unittest píše človek, čo napísal aj kód, ktorý má ten test testovať, nie je príliš prekvapujúce, že často nefungujú ak sa trochu zmenia niektoré parametre).

Podľa mňa je rozumné napísať test len v prípade, keď sa opraví nejaká chyba, aby sa rovnaká chyba už nevyskytla.

PS: Najrozumnejšie je mať kvalitné revidovanie kódu, odhalí sa tak veľa problémov a nemôže sa stať, že daný kód bude poznať jediný človek.

Tak vieš, 100% pokrytie neznamená nič. Dôležité je len to, ako sú tie testy písané a či testujú naozaj potrebné scenáre, a nielen to, aby získal programátor 100% coverage.
Revidovanie kódu je fajn, ale na to potrebuješ viacerých programátorov, ktorí na tom pracujú. Čo ale v prípade, kedy ako napríklad ja pracuje človek zväčša sám a dostáva projekty po takisto sólo programátoroch? Naozaj utrpenie študovať také programy, občas sa bojím urobiť aj najmenšiu zmenu, aby som nenarobil viac škody ako úžitku.

Ide tam o to, že pokiaľ človek nepíše testy vôbec, respektíve "len keď sa mi zachce", väčšina programátorov nepozerá až tak na kvalitu a jednoduchosť kódu. Proste to vyzerá fajn, pridajú tam viacero threadov a fičí sa. Pokiaľ ale programuješ tak, aby to bolo ľahko testovateľné, väčšinou sa nebudeš púšťať do nejakých prekomplikovaných stavov. Snažíš sa vždy nájsť čo najjednoduchšie riešenie a inkrementálne pridávaš funkcionality. Preto o TDD neuvažujem ako o nejakom testovacom postupe ale skôr ako o spôsobe navrhovania architektúry softwaru...


Ani nespomínaj, neviem, čo je to dnes za trend, ale vidno to krásne aj tu na pcfóre, ale povedzme aj na StackOverflow. Ľudia nemajú problém drbnúť holý SQL príkaz (častokrát ešte aj s viac ako očividným SQL injection) priamo do UI code-behindu, priamo do handlera udalosti. Žiadna abstrakcia, žiadne vrstvenie softwaru, všetko pekne nakopu a sú neskutočne prekvapení, že im to "nefunguje".
Alebo pri webforms dokonca švahnú ten SqlDataSource priamo do aspx stránky medzi html Keď vidím SQL + html hneď vedľa seba, príde mi vždy zle. Neviem, čo Microsoft napadlo podporovať takú zvrhlosť.