BUTHRAKAUR: Tak ono jde o scenar kdy ten test delas. Jestli pri vytvareni nove funkcionality nebo pri refactoringu (kdyz testy na refactorovanou ficuru neexistuji).
Ja netestuju vsechno. Je hromada veci, pro ktery to nema smysl (napr. obycejny getery, settery) a pri rozsirovani funkcionality proste nekde pribyde metoda, ktera by si ale test uz zaslouzila. Prijde mi pohodlnejsi si tam napsat signaturu ty metody, do ni hodit NotImplementedException a nechat si pro ni vygenerovat torzo testu nez naopak.
Postup "vytvorit nezkompilovatelnej test, nechat ho nezkompilovat, pak vytvorit metodu, dosahnout tak zkompilovatelnyho testu, a ted teprve psat test" mi prijde zbytecne komplikovanej. Krok 1 a 2 imho muzu rovnou preskocit. Protoze tim neziskam.
Nemyslim si, ze bych timhle postupem neco realne zlepsil nebo zhorsil Prijde mi to spis, ze to je o osobnich preferencich. Vysledek je imho shodny.
Tim prejmenovanim metody jsem mel na mysli, ze kdyz v projektu prejmenuju metodu, tak chci aby se mi prejmenovala i uvnitr testu. Cili ne nazev toho testu. Takze kdyz bych k tomu pristupoval pres "dynamic" tak by pri automatickym refactoringu k prejmenovani toho volani v testu nedoslo.
U testovani privatnich clenu - religiozne spravne by se to nemelo delat. Nicmene nekdy scope dotycny metody je private/protected/internal a ne public z duvodu architektury systemu. Pricemz ale character ty metody je takovy, ze by si ten test zaslouzila. Co pak? Imho je lepsi se "nejak dobouchat" na tu metodu a udelat na ni test, nez ten test nedelat. A nebo tu metodu udelat public a pak se snazit pres dokumentaci prijmout "verejnost" aby ji nepouzivala.