@Riddle każda skrajność jest zła. Ty z braku testów poszedłeś do jakiejś abstrakcji w drugą stronę. Co mam powiedziec szefowi ze nie bedzie zmian o ktore prosil bo poprawiam bugi w chrome driverze?
To mi pachnie złym symptomem, czyli robienie złych/słabych testów, przez pressure z góry. To jest bardzo zły symptom, świadczy o braku asertywności i w gruncie rzeczy braku profesjonalizmu. Ty jako programista masz wiedzieć co jest ważne żeby dostarczyć feature. I testy jaknajbardziej są ważne.
Poza tym, czemu miałbyś mu powiedzieć że nie będzie zmian? Powiedz mu "Dodanie tego feature wymaga żeby go odpowiednio zaprogramować", zaczynasz robić, robisz w małych krokach, i dostarczasz funkcje po kolei. I w "zaprogarmować" jest oczywiście "napisać kod" oraz "napisać testy". Testy to jest nieodzowna część developmentu.
To że myślisz o tym w odrębnych kategoriach, że jakoś napisanie testów to jest coś dodatkowego/opcjonalnego bardzo źle świadczy.
Testy powinny być takie zeby dac nam znac ze aplikacja dziala ok. Jak sa niestabilne to mozna ustawic rerun jeśli w zespole sobie ustalimy ze dla nas to jest ok.
To jest bardzo słabe. Gratuluję pracy w takim stylu.
Czyli tak na prawdę mockować część ścieżki, co może i będzie szybsze, ale zaburzy cały proces i może być false positive.
Czemu miałoby zaburzać proces?
I jeśli może być false positive, to ten jeden test który ma prawdziwą, niezmockowaną ścieżką go złapie.
Jak wyżej. Jeżeli mam proces zależny od zasobów cloudowych i chce przetestować całą integrację z tym związaną to siłą rzeczy muszę polegać na cloudzie (Jednocześnie akceptując wszystkie opóźnienia z tym związane). Oczywiście mogę sobie wszystko imitować lokalnie i znowu to co wyżej -> duża szansa false positive.
Czyli mówisz, że jeśli Twój codebase jest poprawny, ale nie działa jakiś cloud sieciowy, to chcesz żeby Twoje testy lokalne sfailowały? Po co?
@ledi12 Ja nie mówię Ci jak masz robić te testy, możesz je pisać jak chcesz. To co Ci mogę powiedzieć na 100%, to to, że wolne testy po pierwsze bardzo przeszkadzają w pracy, a po trzecie w każdym jednym przypadku da się je przyspieszyć do sensownych prędkości, i absolutnie nie kupuję wiadomości że "nie da się", bo ja od wielu lat tak pracuję, też integruję się z wieloma systemami, i jakoś nigdy nie mam testów które długo trwają. Jak pisałem, nie jest łatwe to zrobić, ale da się.
To nie kwestia przekonania. Są testy, które mogą być szybkie (Unity, logika sama w sobie) i są też testy e2e (end to end, integracja, zwał jak zwał) które powinny bazować w pełni na finalnych zasobach (cloud, kafki itp) a to wiąże się z konkretnym czasem egzekucji. Tylko wtedy mam pewność, że mój program działa w pełni. Kombinacje / mockowanie mi tej pewności nie dają.
które powinny bazować w pełni na finalnych zasobach I tym finalnym zasobem jest coś Twojego, czy zewnętrznego? Jeśli Twojego, to masz kontrolę nad tym żeby to przyspieszyć do testów. Jeśli nie Twojego, to Twoje testy nie powinny failować jak to coś nie działa. Powinny sfailować tylko jak Twój program nie działa.
Tylko wtedy mam pewność, że mój program działa w pełni Twój program, czy zależności Twojego programu, nad którymi i tak nie masz kontroli?
Bo testy nie powinny failować jeśli jakaś zależność sieciowa zewnętrzna leży.
Jeśli piszesz program który korzysta z zewnętrznego serwisu (np stripe), to Ty nie masz nad nim kontroli. Jedyne co możesz zrobić, to obsłużyć w swojej aplikacji co Twoja aplikacja ma robić jak ta apka padnie, i pod to powinny być testy.
Dodatkowo - testy powinny przechodzić dla danego commita nie zależnie od daty. Jeśli piszę kod, odpalam testy, one przechodzą, robię commit, i teraz nagle stripe pada, to jak wrócę na mój commit, to testy mają mi dać dokładnie taki sam wynik jaki dały w momencie robienia tego commita.
To o czym mówisz, że Twoje testy miałyby zależeć od zewnętrznego providera, to jest dodanie tight-coupling na coś co po pierwsze jest mega wolne, a po drugie nie masz nad tym kontroli w ogóle. To jest bardzo zły pomysł. I robisz to wszystko w imię "sprawdzenia czy mój system działa", tylko że sprawdzić czy system działa da się dużo lepiej i szybciej, niż faktycznie strzelać do zewnętrznego serwisu.