@uetoyo
Ale já tyto věčné debaty ohledně strategie testováni znám. Samozřejmě na to mám svůj názor, argumenty a znám i spoustu argumentů ostatních stran. Tak argumentuji, nemusím se schovávat za obecné odkazy a tvrzení demonstrované na urcitých řekněme specifických pripadech. Dokonce existují i názory že stačí jenom plné unit testy, někomu stačí jenom code coverage a dokonce jsem nedávno mluvil s člověkemz jiné firmy který se přiznal že nedavno na pohovoru rekl ze testy jsou ztrata času - vsak vi co měnil. To vám neprisuzuji, to jenom abyste videl že tezí je mnoho, já měl za to ze se bavime o reálné praxi a zkusenostech.
Jako myslete si o mě co chcete, ale z denodenní praxe testování vím, že se celkem často chyba nebo zmena projeví i vvdalsich vrstvach aplikace - ono je to taky logicky tím že ty tvrsvy a jejich akce jsou na sebe navázané.
No a speciálně pro Vás: Začnete mluvit o "řezu vrstvami", občas to vztáhnete jenom na vrsrvu persistence (jako v itaci vyse) a příklad dáte s funkcí v nějaké evidentne jednovrstvé implementaci. Asi byste si ty okazy měl projít nejprve sám a pak to vyzkouset i prakticky. Já Vám prakticky priklad dam.
Nedavno jsem opravoval funkci v jedné službě (třída), unit testy jsem upravil, pustil jsem functionalni testy podle jmena (asi 3) a zjistil jsem, ze v jine metode kde je tato funkce pouzita v jednom prípade nastane situace ktera me nenapadla. Kdybych to chtěl zkoušet normálně v dev instanci tak budu muset naklikat asi 4-6 scénářů. Takže behem minuty jsem to zjistil, pak opravil a nechal při MR jet v pipeline testy 25 minut. Tak Vám děkuji za praktickou radu nepustit func. test na localhostu a cekat ? času na pipeline a mezitím někde začínat neco druhého a pak snad i třetího a kdovi kolikátého. Dekuji, rozhodně se Vaší rady drzet nebudu