@jarekr000000
Te testy "po", już niczego nie wnoszą
Ktoś chyba nigdy nie słyszał o czymś takim jak regresja albo o błędach zwiazanych z refaktoryzacją kodu. Serio czasem czytając twoje posty zastanawiam sie czy pracowałeś dłużej przy jakimś (starszym) projekcie w fazie utrzymania. Staż by sugerował że musiało tak być, ale to co piszesz nijak...
Oczywiście jeśli ktoś chce ocenić jak przydatne są testy w chwili ich napisania zaraz po implementacji to wartość jest zerowa, o ile programista nie jest idiotą i nie napisał niedziałajacego kodu. Ale wartość testów wychodzi znacznie później, kiedy ktoś zaczyna coś refaktorować, zmieniać technologię, migrować itd.
Oj @Shalom - jak co nie pasuje do twojej wizji to musi być głupek pisał ... podoba mi się twój tok rozumowania.
Ale ciekawostka - od nastu lat najwięcej zarabiam właśnie na nekromancji - czyli utrzymaniu w ruchu - a nawet rozwoju - mniej lub bardziej starych systemów (choć ostatnio mam wrażenie, że 3 lata to już stary - ale powiedzmy, że obecnie np. tykam kodu mającego max 8 lat - gdzie pare pokoleń programistów się przewinęło... ;-)). Przy okazji: te "stare" systemy nawet lubię: tu są wyzwania :-).
Wnioski wyciągam na podstawie... pieniędzy - w działającym, rozwijanym systemie zawsze jest mnóstwo miejsc, które można poprawić - i trzeba priorytetyzować - co najbardziej się opłaca. Pisanie testów po implementacji uznałem już dawno za nic nie wnoszące - bo się zwykle nie wywalają.
A co w przypadku refaktoryzacji? no właśnie - jak ktoś taką robi na kodzie, który nie ma testów to właśnie jest moment zapłaty. Zanim się zacznie - trzeba napisać testy. Dokładnie tak samo w przypadku bugu.
Testy zrobione "zaraz po implementacji" i tak mam w całej masie, i jak to w testach robionych po -> wszystko jest na Mockito. Nawet po usunięciu implementacji potrafią nadal zakończyć się sukcesem :-) (A próba refaktoryzacji niezmiennie kończy się koniecznością jednoczesnej zmiany i kodu i testów... czyli totalnie bez sensu).