W Facebooku nie piszą testów

@katakrowa: testy jednostkowe są testami jakiegoś modułu. Np. masz moduł do tworzenia faktury, która nie ma zewnętrznych zależności to możesz nazwać ten moduł jednostką. Błędem jest założenie, że unit testy testują pojedyncze klasy i musisz wszystko mockować. Testy jednostkowe nie betonują Twojego codebase'u jak inputuje to ten gość na filmie bo mając jasno zdefiniowane kontrakty na poziomie modułów możesz sobie podmieniać te moduły na lepsze implementacje zachowując dany kontrakt i testy z tym związane. Temat był poruszany wielokrotnie na tym forum.

Użytkownik @Riddle to ładnie wypunktował. Koleś z filmu wypaczył sobie definicję testu jednostkowego, stworzył chochoła, obalił go i ogłosił zwycięstwo. Tyle tylko, że pochwalił się jedynie swoją niekompetencją.

@katakrowa:

Nie. To jedynie jeden ze sposobów. Być może najpopularniejszy ale ani ogólny ani niezastąpiony ani najtańszy

Jednak nie, bez testowania, jakiegokolwiek, nie widzę inzynierii; i pytanie, skąd mam wiedzieć, że kod bez testów działa? Nie wiem, dlatego go [ten kod] wrzucam do "legacy shit":)

@lion137: Zgadzam się, że "jakiekolwiek testowanie" jest podstawą inżynierii. Jak ktoś mądry, kiedyś napisał "każda firma ma środowisko testowe, niektóre mają szczęście mieć również osobne środowisko produkcyjne". Coś jak medycyna przez wiele lat (a właściwie do tej pory), zastosują jakąś terapię i będą sprawdzać, czy pacjent przeżył.

@twoj_stary_pijany:

@katakrowa: Jeżeli budujesz most to możesz go przetestować, jeżeli tworzysz lekarstwo to je również testujesz w skomplikowanych badaniach klinicznych. Producenci samochodów robią crash testy. Ale programiści są geniuszami i nie potrzebują udowodnić, że ich gówniany kawałek kodu robi to co miał w założeniach robić.

koszt fixa w web appce: 17zł

koszt zmian/odszkodowań dla sprzedanych samochodów: miliony usd (PR, logistyka, materiały, management, etc.)

PS: ja to bym uważał z używaniem słowa udowodnić na tym forum :D

koleś tam chyba mocno namotał, bo w tytule jest "why i don't unit test", a potem pokazuje tweety z treścią np. "i haven't written any test in 5 years". no to w końcu chodzi o unitowe czy jakiekolwiek? potem jednak (moment ok 1:45) rozgranicza testy na unitowe, integracyjne i e2e, a więc to sugeruje, że pomija tylko pierwszą kategorię, a resztę zostawia. w 2:22 nawet mówi o tym wprost: "the best ways don't tend to be testing at all, if they are they are integration and e2e testing". w 5:07 mówi o tym, że zaledwie w 3 przypadkach testy unitowe mogłyby wykryć błąd przed wdrożeniem na produkcję (i że 2 przypadki były i tak zbyt skomplikowane na unit test) - to jest trochę średnie, bo unit testy są raczej po to, by skrócić feedback do kilku minut albo ułamka minuty, a nie po to, by wykrywać nimi wszystkie problemy, które chcemy wykryć (mamy przecież wiele poziomów testów, nie tylko unitowe).

w 6:01 zaczyna się gadka o usztywnianiu (cementowaniu) kruchego kawałka kodu unit testami, po to by go łatwo nie zepsuć. dla mnie to brzmi jak mockowanie wszystkiego jak leci (kopiowanie logiki produkcyjnej do mocków), po to by nie dało się zmienić kodu produkcyjnego bez mockowania od nowa. "you took thing that barely works and you duct taped and cemented it in place so it can't ever move so it's less likely to break". prawdopodobnie padł ofiarą mocksturbacji (określenie od @jarekr000000 - może zweryfikować czy właściwie użyte :) ) i myśli, że wszystkie unit testy powielają ten schemat. kolejne stwierdzenie utwierdza mnie w przekonaniu, że tak właśnie było: "the time spent reinforcing it with unit tests to double or more the amount of code just to make sure that thing doesn't break again it's time you could almost always have spent rewriting the thing so it's less fragile in the first place". przy mockowaniu jak leci refaktor czy przepisywanie kawałków kodu od nowa jest utrudnione, ale jeśli ograniczamy używanie mocków do minimum to testy wręcz nam ułatwiają przepisywanie badziewnej logiki na lepszą, bez psucia samego obserwowalnego z zewnątrz zachowania kodu.

wielokrotnie pojawia się motyw pokrycia kodu i nacisku na to. tylko kto faktycznie się tym przejmuje? w firmie włączyłem pokrycie kodu we wszystkich bibliotekach i mikroserwisach, które mamy (trochę pracy z tym było). ostatecznie tylko ja sprawdzałem to pokrycie i to tylko przez pewien czas, bo szybko mi się znudziło. reszta ludzi w zespole widziała to pokrycie chyba tylko na demie, który robiłem i tyle. możliwe, więc że ktoś go skrzywdził tym naciskiem na pokrycie testami: 7:16 "if you have one of those dumb 100 code coverage rules at work and some senior engineer from ex-amazon or some that insists you all need 100 code coverage everything's going to go to hell send them this video seriously". ja jednak nie znam tego typu historii.

wielokrotnie pojawia się stwierdzenie typu: "build safety nets not guardrails". ee, tylko jaki jest koszt tworzenia tych safety nets? jak wygląda konkretne porównanie między nimi, a unit testami? nie wiadomo. wiadomo jednak, że jeśli ktoś z tego filmiku wywnioskuje, że może po prostu wywalić testy i świętować sukces to na pewno nie zrozumiał przekazu, bo pominął kluczowe dla całego wywodu zastępowanie testów tą totalnie niesprecyzowaną "safety net".

@Wibowit: To chyba jest parę problemów złożonych do kupy. Pierwszy, to odwieczna dyskusja o tym "czym jest ten unit", często prowadzona w sytuacji, w której aplikacji na testowalne unity nie da się podzielić. Drugi problem, to mówienie o wszystkim co jest pod @Test "unit test", chociaż mogą tam być właściwie wszystkie możliwe rodzaje testów. Wreszcie jest powszechny w IT cargo cult buzzwordów i traktowanie wydawałoby się prostych do zrozumienia zasad jak reguł jakiejś religii. Mam na myśli frazesy typu "testy muszę się wykonywać szybko", nawet jak to jest absolutnie niemożliwe, bo podstawowy proces aplikacji trwa kilka godzin. Gorzej jest już chyba tylko z fanatycznymi wyznawcami clean code, dla których każdy komentarz to zło, prawie jak jedzenie mięsa w piątek. Nie ma znaczenia, że w środku jest jakiś porąbany wzór matematyczny, albo użyty konkretny algorytm i dodanie tam linku do dokumentacji, czy napisanie dlaczego użyto, takiej a nie innej metody rozwiązania problemu mogłoby oszczędzić mnóstwo czasu.
W przypadku testów jednostkowych, rozumianych jako testy pojedynczej, przypadkowej klasy, to dość oczywiste jest, że taki test niczego nie testuje, zwykle betonuje implementację i zarówno jego pisanie, jak i utrzymywanie jest stratą czasu. Co komu po teście, który trzeba zmienić, przy każdej zmianie testowanego kodu?

Kiedyś robiłem w projekcie gdzie była każda klasa przetestowana, a każda zależność było mockiem. Wyglądało to tak, że 60% linijek faktycznej implementacji odwoływała się do mocka, a test sprawdzał wywołania mocków.
Test głównie polegał nie na sprawdzeniu wyników, a na weryfikacji mocków. Zmiana czegokolwiek była niemożliwa, nawet wywołanie zależnych serwisów w innej kolejności często wywalało testy. W takiej sytuacji jakikolwiek refaktor był niemożliwy, już lepiej nie mieć testów niż mieć takie.

Sam natomiast staram się testować jak opętany do przesady. Sprawdzam czy cache działa i faktycznie cachuje, czy circut braker się zamknie jak wiremock rzuci 500, no staram się dosłownie wszystko udowodnić testami i nie wiem czy nie przesadzam w tę stronę (odwrotną do tezy z filmu). Jeżeli jest jakiś skrypt migracyjny to zawsze powstaje osobny test, jeżeli jest skrypt w bashu, który zostanie uruchomiony na produkcji to też staję na głowie, żeby przetestować automatycznie