@wombatDaiquiri Nigdy nie jesteś pewien na 100%, więc testy są konieczne: po prostu z reguły UT są najmniej użyteczne. Generalnie chodzi o to żeby tworzyć zmiany małymi krokami, używając do tego bardzo małych commitów, jednocześnie nie zmieniając zachowania tam gdzie nie trzeba.
Podam Ci przykład jak do tego podchodzę:
Zmiana w aplikacji rozszerzającej zachowanie jakiegoś modułu.
Zaczynasz od refactorów, które mają nie zmieniać zachowania klasy. Każdy refactor to osobny commit. Każdy commit musi być czysty (tzn nie zawierać innych zmian, nie będących częścią tego co robisz), więc np:
- osobny commit na uporządkowanie zmiennych w funkcji, tak, żeby dało się jej część wyciągnąć robiąc niewiele więcej niż kopiuj-wklej,
- osobny commit na wydzielenie metody,
- itd.
Generalnie osobny commit na każdy krok refactoringowy. Podobnie przy dodawaniu nowego kodu, idealnie byłoby podzielić go na kawałki.
Każdy commit musi działać! (przechodzić wszystkie testy itp)
Z reguły zmiany wprowadzające zmianę zachowania są na końcu takiego brancha/patchsetu i powinny być tryawialne: żebyś był w stanie szybko je wycofać, ale też szybko wyłapać jakiś problem.
Wiadomo - przeoczysz wiele błędów. Ale jeśli przy każdym commicie przejrzysz zmiany które zrobiłeś, zmniejszasz szansę na wprowadzenie regresji, i to wielokrotnie. Pomaga przy tym pisanie dobrych opisów commitów: opisując nie "co zrobiłem" tylko "po co to zrobiłem" - to "co zrobiłeś" widać w commicie, zwłaszcza jeśli jest mały i prosty. Pytanie "dlaczego ten commit zrobiłeś" jest jeśli nie nieoczywiste to na pewno trudne do zgadnięcia. Finalnie: odpowiedź na to pytanie wiele razy sprawiła że wywaliłem dane zmiany jako kompletnie niepowiązane ; D.
To jest workflow do którego się trzeba przyzwyczaić, wymaga dużo czytania i rozumienia kodu, ale bardzo szybko powoduje, że nie dość że robię o wiele mniej błędów, to do tego bardzo dobrze rozumiem co się dzieje w kodzie - żeby przygotować dobry patchset musisz dobrze zrozumieć co robi kod w którym pracujesz.
Prywatnie zmieniło to moje podejście do pisania kodu o 180 stopni. Jeśli zaczniesz stosować ten workflow i nabierzesz wprawy zaczynasz pisać kod paradoksalnie bardzo szybko i bez błędów - nie marnuję czasu na debugowanie, bo najczęściej nie mam po co go robić.
I powoduje że UT są po prostu upierdliwe, bo przenoszę ciężar z "napisz kod produkcyjny i opisz go testami" na "napisz kod produkcyjny tak żeby działał i nic nie popsuł". Testuję go najczęściej tylko manualnie wysokopoziomowo, czasem piszę i odpalam testy modułowe/systemowe.
