Mockowanie

[MateuszNaKodach]

Summary:
Dyskusja przedstawiona w dokumentach oraz dodatkowe źródła wskazują na kilka istotnych problemów związanych z nadmiernym lub niewłaściwym używaniem mocków w testowaniu:

Mocki mogą prowadzić do "betonowania" kodu testami, które nie sprawdzają rzeczywistych zależności. Testy stają się zbyt ściśle powiązane z konkretną implementacją, co utrudnia późniejsze zmiany w kodzie.
Nadmierne używanie mocków może prowadzić do tzw. "mock hell" - sytuacji, gdzie testy stają się trudne do utrzymania i zrozumienia ze względu na dużą liczbę skomplikowanych mocków.
Mocki często testują implementację, a nie zachowanie. To może prowadzić do testów, które przechodzą, ale nie odzwierciedlają rzeczywistego działania systemu.
Testy z mockami są często bardziej kruche - łatwiej się "psują" przy zmianach w kodzie, co może prowadzić do fałszywych negatywów lub pozytywów.
Mockowanie bibliotek zewnętrznych może być szczególnie problematyczne, ponieważ prowadzi do testów, które są ściśle powiązane z API tych bibliotek, co utrudnia późniejsze zmiany lub aktualizacje.
Mocki mogą dawać fałszywe poczucie bezpieczeństwa, tworząc testy, które przechodzą, ale nie odzwierciedlają rzeczywistego zachowania systemu w produkcji.
Nadmierne poleganie na mockach może prowadzić do projektowania systemu w sposób, który utrudnia testowanie bez nich, co może być szkodliwe dla ogólnej architektury.
Mocki utrudniają debugowanie, ponieważ nie odzwierciedlają rzeczywistych obiektów i interakcji w systemie.

Eksperci, tacy jak Dave Farley czy Justin Searls, zalecają ostrożność w używaniu mocków i sugerują alternatywne podejścia:
Tworzenie małych, dobrze zdefiniowanych abstrakcji zamiast mockowania dużych, złożonych zależności.
Używanie rzeczywistych obiektów zamiast mocków tam, gdzie to możliwe.
Stosowanie testów integracyjnych zamiast jednostkowych z mockami dla bardziej złożonych scenariuszy.
Projektowanie kodu w sposób umożliwiający łatwe testowanie bez mocków (np. poprzez odpowiednie wydzielanie modułów).
Używanie mocków tylko w szczególnych przypadkach, np. dla zewnętrznych API, gdzie każde wywołanie jest kosztowne.

Podsumowując, choć mocki mogą być użytecznym narzędziem w niektórych sytuacjach, ich nadużywanie może prowadzić do wielu problemów z jakością i utrzymaniem testów oraz kodu. Kluczowe jest znalezienie odpowiedniej równowagi i stosowanie mocków z rozwagą, mając na uwadze długoterminowe konsekwencje dla projektu.
Podsumowanie dyskusji na temat Result vs Exceptions w programowaniu wskazuje na kilka istotnych zalet podejścia opartego na Result:

Jawność i bezpieczeństwo: Result wymusza na programiście jawne obsłużenie potencjalnych błędów, co prowadzi do bardziej przewidywalnego i bezpiecznego kodu. "Result powoduje, że musimy pomyśleć o tym, że może wystąpić konkretny inny przypadek".
Elastyczność: Result pozwala na bardziej elastyczne podejście do obsługi różnych scenariuszy. Jak wspomniano w dyskusji, "Nie zawsze error jest jedyną możliwością. Czasami rekompensativy event może nią być. RevokedSubcribePlan etc."
Rozszerzalność: Łatwiej jest rozszerzać funkcjonalność Resulta o dodatkowe konteksty, np. "Retry lub inny context", co zwiększa możliwości kontroli przepływu programu.
Wydajność: "Resulty są dużo szybsze". To spostrzeżenie jest zgodne z informacjami z innych źródeł, które sugerują, że obsługa błędów przez Result może być bardziej wydajna niż mechanizm wyjątków, szczególnie w językach kompilowanych.
Łatwiejsze testowanie: "resulty łatwiej testować", co jest istotną zaletą w kontekście zapewnienia jakości kodu.
Brak problemów ze stosem wywołań: "Na poziomie parsowania takiego języka nie musimy martwić się o globalny stack z errorami". To eliminuje potencjalne problemy związane z przepełnieniem stosu, które mogą wystąpić przy nadmiernym użyciu wyjątków.
Lepsza kontrola przepływu: Result pozwala na bardziej precyzyjną kontrolę przepływu programu, bez "ukrytych" ścieżek, które mogą pojawić się przy użyciu wyjątków.
Zgodność z paradygmatem funkcyjnym: Podejście oparte na Result jest bliższe programowaniu funkcyjnemu, co może prowadzić do czystszego i bardziej przewidywalnego kodu.
Warto zauważyć, że choć podejście oparte na Result ma wiele zalet, wybór między Result a Exceptions często zależy od konkretnego kontekstu, języka programowania i preferencji zespołu. "Tutaj wchodzi dużo innych czynników jak, idiomy w języku, podejście zespołu, wiedza w zespole, ogólne standardy w danej technologii etc."
Podsumowując, Result oferuje bardziej eksplicytne, bezpieczne i elastyczne podejście do obsługi błędów, choć może wymagać nieco więcej kodu i przyzwyczajenia się do nowego paradygmatu.