W Facebooku nie piszą testów

0

Oczywiście tytuł kontrowersyjny i na pewno nie dotyczy całego FB :) W każdym razie, co sądzicie o tym tweecie? https://twitter.com/ptashek_eire/status/1550492213334925313 Do tego dorzucam filmik na temat właśnie tego tweeta: Zapraszam do dyskusji :P

2

Programiści, którzy nie testują swojego kodu niczym nie różnią się od Jerzego Zięby obiecującego leczenie raka witaminą C. Udawanie, że wykonało się swoją pracę. Rzeczywistość wygląda tak, że tacy programiści tylko delegują testowanie na inne osoby, które muszą później nadzorować pracę tego programisty, który wszędzie wali błędy. W konsekwencji perfomance wszystkich spada podczas gdy performance naszego Jerzego Zięby nadzwyczajnie rośnie i staje się on gwiazdą Facebooka.

8

Programiści, którzy nie testują swojego kodu niczym nie różnią się od Jerzego Zięby obiecującego leczenie raka witaminą C.

Jednak pisanie "testów" nie jest tu złotym środkiem. Zarówno z nimi jak i bez nich można pisać i dostarczać odbiorcy bardzo dobry i niezawodny kod.

0

Facebook ma taką pozycję, że i tak ludzie od niego nie uciekną. Jakby w Polsce był tylko jeden bank, to też by się zachowywał tak, jak mBank w tym względzie.

1

@katakrowa: alternatywą jest zatrudnienie armii testerów, którzy przy każdej zmianie testują czy nie powstała regresja w funkcjonalnościach, które ktoś dodał dawno temu. I koszty braku testów przenosisz na pensje tych testerów. Czyli jeden dział w firmie wykazuje zysk, a inny wykazuje straty. Ale każdy manager uzasadnia sobie wyniki finansowe w inny sposób jednocześnie będąc podatnym na błędy poznawcze bycia w lokalnej bańce.

Chyba, że robisz portal do wyświetlania obrazków i twoimi testerami są klienci końcowi. W takim wypadku przerzucasz koszt testów regresji na klienta. Jeżeli jest to klient biznesowi to taki klient również ponosi koszty bo pracownicy danej firmy nie mogą korzystać z narzędzia w trakcie swojej pracy. Jeżeli jest to klient indywidualny to taki klient po prostu się zdenerwuje i może wróci później, a może nie.

1

Troszkę naiwne podejście. Zgaduje, że jego projekt był napisany w taki sposób, że testy nie były wymagane, bo technologie i scope projektu taki był. Niektórzy uznają, że monitoring is new testing i myślę, że w dużych korpo ma to sens, bo monitoring może być dobry poprzez uwspólnienie praktyk i władowanie kupy kasy, że faktycznie jest duża grupa aplikacji, która może się bez tego obyć.

Jakie widzę problematyczne sytuacje, gdzie mamy super monitoring i brak testów:

  • jak testować logikę niezwiązaną z naszym kodem? Przykładowo piszę zapytanie SQLowe, którego nie jestem pewny i nie da się tego sprawdzić bez bazy, która musi być w jakiś sposób wypełniona. Jak mam testy integracyjne to piszę test i w parę sekund mam feedback, przy deployu na produkcję mamy wspomniane 7 minut
  • jak testować, gdy nie mamy jeszcze produkcji albo produkcja słabo pokrywa kod? Feedback w takim przypadku może przyjść po miesiącach, gdy nikt już nie będzie wiedział o co chodzi. Tutaj cała meta jest akurat w dobrej sytuacji, ale to może być ewenement na skalę światową
  • bez testów nie puszczę sobie jakiegoś data race checkera a takie problemy są najgorsze, bo mogą powodować piekielnie ciężkie błędy do wyłapania plus w takich przypadkach wchodzi paranoja, bo już nie wiem czy logika jest zła czy mam gdzieś złe concurrency (może w jednowątkowych programach ten problem jest minimalizowany)
  • używamy dużo współdzielonych bibliotek napisanych w firmie jednocześnie mamy jeden trunk branch, z którego budowane jest wszystko (przypadek googla). W takim przypadku nie wyobrażam sobie testów w bibliotekach, bo wykrycie sedna problemu może kosztować dużo czasu
  • utrudnione review, często po samym testach widać, czy logika ma sens z punktu widzenia biznesu
1

Ale gość pracował jak sam napisał "infra/ops".

0
katakrowa napisał(a):

Jednak pisanie "testów" nie jest tu złotym środkiem. Zarówno z nimi jak i bez nich można pisać i dostarczać odbiorcy bardzo dobry i niezawodny kod.

Nie. Testy to podstawa inzynierii; a że niektórych rzeczy nie da się dokładnie przetestować to inna sprawa, np., jakiś skrypt odpalany Jenkinsowym pipeline, można sobie go unit testować, ale tak naprawdę testem będzie odpalenie buildu.

5

Moje główne projekty są integratorem/frontem dla całego systemu i tak szczerze to wszystkie unity g**no mi/nam dają. I tak musi być to testowane manualnie i tak. A najwięcej bugów to łatanie zachowania innych systemów i error handling errorów infrastrukturalnych typu zerwanie połączenia z którymś systemem itd.
Testów typu na zrywanie randomowe połączeń nie ma sensu robić bo i tak jest paru testerów i dodatkowo i tak jest support 24/7 dla infry, a same licencje dla środowiska testowego to byłoby setki tys dolarów ( oracle <3) także całkiem rozumiem to :p.

2
twoj_stary_pijany napisał(a):

@katakrowa: alternatywą jest zatrudnienie armii testerów, którzy przy każdej zmianie testują czy nie powstała regresja w funkcjonalnościach, które ktoś dodał dawno temu.I koszty braku testów przenosisz na pensje tych testerów.

Nie. Zatrudnienie armii testerów jest jedynie skutkiem zatrudnienia armii nieodpowiedzialnych i zwyczajnie słabych programistów. Do tego dochodzi brak dobrej dokumentacji/projektu systemu i mamy środowisko, w którym testy są ostatnią szansą na to żeby wszystko w ogóle zadziałało. Nie ma to nic wspólnego z dobrą inżynierią ani wysoką jakością. Po prostu wspomaganie mechanizmów maszynki do mielenia dużej ilości mięsa...
Dziś w większości firm 5 programistów z minimalną wiedzą i doświadczeniem robi to co mógłby zrobić jeden dobry tylko dlatego, że tych dobrych na rynku brakuje. Nie znaczy to jednak, że inżynieria oprogramowania będzie w nieskończoność ewoluować w kierunku umożliwienia pracy coraz mniej wykwalifikowanym. W pewnym momencie proste prace zostaną zautomatyzowane i w ogóle ludzie nie będą musieli pisać tego co dziś większość pisze a skoro tak to nie będzie błędów popełnianych przez tych ludzi. W każdej branży na świecie tak się dzieje i tak samo będzie w programowaniu.

lion137 napisał(a):

Nie. Testy to podstawa inzynierii; a że niektórych rzeczy nie da się dokładnie przetestować to inna sprawa, np., jakiś skrypt odpalany Jenkinsowym pipeline, można sobie go unit testować, ale tak naprawdę testem będzie odpalenie buildu.

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

2

A skąd on ma dowód że to co wdrożył działa? /s cc @somekind @scibi_92

@twoj_stary_pijany:

Programiści, którzy nie testują swojego kodu niczym nie różnią się od Jerzego Zięby obiecującego leczenie raka witaminą C. Udawanie, że wykonało się swoją pracę.

no tak, przecież kodu nie można revertnąć i wdrożyć w kilka minut :P


#Thread

Ale skąd ta kontrowersja? są różne softy i czasem faktycznie nie opłaca się pisać testów, tyle.

Wrzucą nowy kod do 1% userów, pewnie w ciągu 15min będą wiedzieć czy są problemy i ewentualnie poleci revert.

Move fast and break things mówi to coś?

Tytuł wątku niestety bardzo pudelkowy W Facebooku nie piszą testów, gdzie w rzeczywistości Jeden devopsiarz z FB(?) twierdzi że przez 5 lat nie napisał testu

1
katakrowa napisał(a):

Nie. Zatrudnienie armii testerów jest jedynie skutkiem zatrudnienia armii nieodpowiedzialnych i zwyczajnie słabych programistów. Do tego dochodzi brak dobrej dokumentacji/projektu systemu i mamy środowisko, w którym testy są ostatnią szansą na to żeby wszystko w ogóle zadziałało. Nie ma to nic wspólnego z dobrą inżynierią ani wysoką jakością. Po prostu wspomaganie mechanizmów maszynki do mielenia dużej ilości mięsa...
Dziś w większości firm 5 programistów z minimalną wiedzą i doświadczeniem robi to co mógłby zrobić jeden dobry tylko dlatego, że tych dobrych na rynku brakuje.

@katakrowa: Gdzie są ci nieomylni programiści, co nigdy nie popełniają błędów i ich kod nie potrzebuje żadnych testów?

BTW: Piszecie testy w Waszych projektach?

5
katakrowa napisał(a):

Nie. Zatrudnienie armii testerów jest jedynie skutkiem zatrudnienia armii nieodpowiedzialnych i zwyczajnie słabych programistów.

20 lat minęło od czasu, gdy Joel Spolsky pisał o tym Top Five (Wrong) Reasons You Don’t Have Testers no ale on może nie mieć pojęcia o inżynierii oprogramowania.

3
nobody01 napisał(a):

Oczywiście tytuł kontrowersyjny i na pewno nie dotyczy całego FB :) W każdym razie, co sądzicie o tym tweecie? https://twitter.com/ptashek_eire/status/1550492213334925313 Do tego dorzucam filmik na temat właśnie tego tweeta: Zapraszam do dyskusji :P

Ten gość nie mówi o pisania testów ;|

On tam używa słów "nie pisz unit testów - pisz testy integracyjne". Tylko że autor filmu używa określenia "unit test" jako test o wysokim związaniu testu z implementacją o małym scope'ie - i argumentuje że one spowalniają development; oraz używa określenia "integration test" jako test na granicach modułów, np testy interfejsów, i mówi że one są odporniejsze na zmiany.

Pies ma cztery nogi, ale jeśli nazwę moją papugę "pies", to to nie znaczy że ona też ma cztery.

1

Nie. Zatrudnienie armii testerów jest jedynie skutkiem zatrudnienia armii nieodpowiedzialnych i zwyczajnie słabych programistów. Do tego dochodzi brak dobrej dokumentacji/projektu systemu i mamy środowisko, w którym testy są ostatnią szansą na to żeby wszystko w ogóle zadziałało. Nie ma to nic wspólnego z dobrą inżynierią ani wysoką jakością. Po prostu wspomaganie mechanizmów maszynki do mielenia dużej ilości mięsa...

No właśnie, a przeciez można zrobić jak jakiś germański architekt czy tam menadżer - zakazał @jarekr000000 tworzenia błędów w kodzie i wszystko jest OK. I po co wam wtedy testy?

PS
Nie pisanie unit testów !== nie pisanie testów

4
nobody01 napisał(a):
katakrowa napisał(a):

BTW: Piszecie testy w Waszych projektach?

Jak zacząłem pisać ponad 20 lat temu tak do dziś testów i wątpię, że będę. Ani ja ani programiści, z którymi od niemal tylu samu lat współpracuję.
Owszem błędy się trafiają jak wszędzie ale ich ilość jest tak mała, że pisanie testów byłoby zwykłą stratą cennego czasu.

Saalin napisał(a):

20 lat minęło od czasu, gdy Joel Spolsky pisał o tym Top Five (Wrong) Reasons You Don’t Have Testers no ale on może nie mieć pojęcia o inżynierii oprogramowania.

Nie każda firma pisze tylko CRUDY, soft dla ubezpieczalni czy banków. Jest cała masa przypadków, w których testy nie tylko nie mają sensu ale także są niemożliwe do napisania w rozsądny sposób. Pisano już na tym forum wiele razy (nie tylko ja).

Poza tym nigdzie nie napisałem, że jestem przeciwnikiem testów automatycznych ale jak widać każde podważenie "wiary w jedynie słuszne testy" musi odbić się dużym echem... Podobno fanatycy tak już mają i samo zasugerowanie, że istnieje inna opcja już wywołuje burzę.

Napiszę zatem jasno - wg mnie w dzisiejszych czasach podczas pisania większości (70% może 80%) kodu testy mogą mieć sens i uzasadnienie biznesowe. Istnieją jednak zagadnienia i obszary programowania, w których testy nie mają najmniejszego sensu a nawet w praktyce są niemal niemożliwe do napisania a już z pewnością nie ma to żadnego uzasadnienia ekonomicznego.

3
katakrowa napisał(a):

Poza tym nigdzie nie napisałem, że jestem przeciwnikiem testów automatycznych ale jak widać każde podważenie "wiary w jedynie słuszne testy" musi odbić się dużym echem... Podobno fanatycy tak już mają i samo zasugerowanie, że istnieje inna opcja już wywołuje burzę.

Napiszę zatem jasno - wg mnie w dzisiejszych czasach podczas pisania większości (70% może 80%) kodu testy mogą mieć sens i uzasadnienie biznesowe. Istnieją jednak zagadnienia i obszary programowania, w których testy nie mają najmniejszego sensu a nawet w praktyce są niemal niemożliwe do napisania a już z pewnością nie ma to żadnego uzasadnienia ekonomicznego.

Ale przetestować aplikację musisz tak czy tak: albo automatycznie albo manualnie (i ktoś to manualnie przetestuje, albo Ty, albo user).

Więc pytanie które uruchamianie testów jest tańsze, manualne czy automatyczne.

Pisanie testów automatycznych owszem, jest bardzo drogie, ale "uruchamianie" manualne jest dużo droższe (nie mówiąc o tym że czas poświęcony na to rośnie wykładniczo).

4

W zależności od tego, co się pisze - testy trzeba mieć lub nie. To samo z testami jednostkowymi. Jeśli piszesz jakieś statyczne utilsy to wtedy naprawdę testy jednostkowe wypadałoby mieć. Tak samo w większości klas. W sumie to jeśli nie jesteś zmuszony do agresywnych optymalizacji to testy powinny być, idealnie jakieś e2e + unit testy części (nie widzę potrzeby testu jednostkowego kontrolera, ale już serwisu biznesowego tak).

Obszary, gdzie niestety trzeba testować na UAT czy nawet PROD to te, które są zależne od infrastruktury. Np. kiedyś mieliśmy aplikację streamującą dane w czasie rzeczywistym i poza sporadycznymi testami e2e (najprostsze przypadki) nikt tam nie pisał - w większości przypadków problemy leżały na styku wydajności i jakości danych. Dosyć trudno napisać test, który sprawdzi, czy aplikacja po przetworzeniu tej masy danych w ciągu miesiąca nie zacznie lagować bo direct buffery nie będą czyszczone odpowiednio szybko.

1

Facebook przez długie lata był napisany w PHP, a jak powszechnie wiadomo, od znajdowania bugów w PHP nie jest kompilator, tylko klient.

Tak bardziej na serio - testy jednostkowe piszę w zasadzie jedynie do jakichś funkcji czy typów pomocniczych, np. gdy mamy w projekcie jakieś funkcje do obrabiania stringów czy jakieś niestandardowe struktury danych. Do reszty raczej testy integracyjne, gdzie z kodu testowego wysyłamy zapytania do API na takiej samej zasadzie, jak robi to aplikacja kliencka.

1
katakrowa napisał(a):

Tu potrzeba albo wybitnego algorytmu albo zwyczajnie człowieka i nie ma innej możliwości.

Jeśli człowiek jest w stanie ocenić czy coś działa poprawnie to można napisać kod, który będzie to sprawdzał w ten właśnie sposób. Trudno powiedzieć z góry co będzie bardziej kosztowne, ale przy odpowiednio długo żyjącym systemie koszt manualnych testów regresyjnych przewyższy koszt napisania testów. Oczywiście, nie dotyczy ludzi piszących kod bezbłędnie, wtedy nie potrzeba testować regresji 🙃

2
Saalin napisał(a):

Jeśli człowiek jest w stanie ocenić czy coś działa poprawnie to można napisać kod, który będzie to sprawdzał w ten właśnie sposób. Trudno powiedzieć z góry co będzie bardziej kosztowne, ale przy odpowiednio długo żyjącym systemie koszt manualnych testów regresyjnych przewyższy koszt napisania testów.

Zazwyczaj takie systemy które żyją dość długo i nie są przepisywane a utrzymywane są to systemy krytyczne dla danego przedsiębiorstwa. I nikt nie pozwoli sobie na to żeby od jakości testów zależało jakość produktów. Jeżeli mój błąd może wysłać ok 15k pracowników na dzień wolnego bo nie będą mieli jak pracować to nawet armia testerów przez lata bedzie tańsza niż 1 dzien przestoju.

0

Gdyby zależało Ci na krytycznych systemach to nie oddawałbyś ich pod opiekę osób, które mogą mieć depresję, miesiączkę, wypadek samochodowy albo się zwolnić bo ktoś się na nich krzywo spojrzał. Nie automatyzując testów jedziesz po krawędzi. Ale to spoko bo ryzykujesz tylko utratę pracy, a nie swoim majątkiem. Manager, który stawia na testy manualne jest ryzykantem idącym all in na preflopie z parą dwójek na ręce. Zawsze może się udać, ale często się nie udaje. Jeżeli się uda to dostajesz awans lub transfer i to jest teraz czyjś problem.

6
katakrowa napisał(a):

Napiszę zatem jasno - wg mnie w dzisiejszych czasach podczas pisania większości (70% może 80%) kodu testy mogą mieć sens i uzasadnienie biznesowe. Istnieją jednak zagadnienia i obszary programowania, w których testy nie mają najmniejszego sensu a nawet w praktyce są niemal niemożliwe do napisania a już z pewnością nie ma to żadnego uzasadnienia ekonomicznego.

Z ekonomicznym uzasadnieniem się zupełnie zgadzam. Zdażyło mi się ubić cały projekt z testami selenium, bo dwóch programistów full time tylko te testy utrzymywało, a nie dość że cały czas były czerwone :-) to jeszcze skutki wywałki w GUI (a to był główny cel) były niezbyt tragiczne i łatwe do naprawienia.

Ale zupełnie inna lekcja jest taka, że najczęściej testy automatyczne mają uzasadnienie tam, gdzie jest je bardzo trudno (wręcz niemożliwe) napisać.

Praktyka jest taka, że programiści napiszą całą suitę testów do "kalkulatora i 2+2", gdzie kod jest trywialny, a nie napiszą testów do np. migracji bazy danych, gdzie błąd może kosztować dość dużo (kto przeżył odtwarzanie systemu działającego na kilku bazach danych, kolejkach i innych cudach z wczorajszych backupów ten wie).

0

@twoj_stary_pijany: system działa od 12-15lat nigdy nie umiem sie doliczyc dokladnie. Rozwijany przez ponad 100 deweloperów. Samych pracowników jest ponad 15k a klientów których tych pracownicy obsługuja dziennie idzie w setki tysiący. Sam mam styczność większą lub mniejszą z tym systemem od 2016/17 i jedyny case gdzie wyjebało nam połowe systemów był spowodowany tym, że kazali dołączyć java-agentów do monitoringu i wysrały sie serwery przez zbyt mała liczbe metaspacu ustawioną. Ja nie ryzykuje niczym tak samo jak ci menadzerowie. Przykład własnie z tym java-agentami do monitoringu kazali wpiac i nie pytac wpielismy i jednego dnia połowa systemów leżała czyli tak tylko z 7k pracowników miało wolne. I na stan mojej wiedzy nikomu włos z głowy nie spadł.

Takze jeśli coś działa tak długo i na taką skalę to chyba działa dobrze ?

Tutaj juz duzo osób wspominało nie każde testy mają sens. Mam testy części systemów ale pokrycie to może 20%.
Jest sporo automatów e2e frontu ale one testuja na mocku wiec same happy scenario i to ze fromularze działają tak jak trzeba a juz corner casow z połączeń pomiedzy systemami i error handlingu nie.

0

Why I don't Unit Test

Nie oglądałem klipu, ale strzelam, że autor mówi o preferowaniu testów integracyjnych/funkcjonalnych a nie testów jednostkowych w rozumieniu testowania pojedynczych jednostek kodu, których używają w systemie (funkcji/klas/whatever).

0

No właśnie nie. Mówił, że wypuszczenie fixa na prod trwa u niego 7 minut i testy ich tylko spowalniają. Mówił ogólnie, że testy rozwiązuje konkretne problemy, które u niego nie występują. Strzelam, że to dlatego, że projekty jeszcze nie weszły w maintanence. Było też trochę o integracyjnych, ale to nie był wiodący temat.

2

W Facebooku jak to w PHP, o błędzie dowiadujesz się od usera ;)

Jest sporo dużych firm z średnimi ludźmi i crapowatym kodem

3

Unit testy nie gwarantują że to co dowoźisz ostatecznie będzie działać. Mnie bardziej irytują ludzie którzy piszą kod i diplojują bez wcześniejszego uruchomienia. A poza tym twoje porównanie jest trochę za ostre programiści nie piszący testów zwykle rozwiązują problem tylko tak jakby nie dają gwarancji co się później będzie z nim działo na produkcji :D — smieszekheheszek 4 minuty temu

@smieszekheheszek: I powtarzające się teksty w stylu:

  • Czy ta historyjka jest skończona? Czy można już ją zamknąć?
  • Tak, jest skończona, zostało mi tylko ją otestować.
  • Czyli jej nie zrobiłeś
  • Zrobiłem w 99%, można zamknąć.
  • Dwa tygodnie temu mówiłeś że była skończona w 90%.

Jakieś kompletne wyparcie rzeczywistości. Dwójmyślenie, historyjka jest jednocześnie nieskończona i skończona.

katakrowa napisał(a):

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

@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ć.

jarekr000000 napisał(a):

Ale zupełnie inna lekcja jest taka, że najczęściej testy automatyczne mają uzasadnienie tam, gdzie jest je bardzo trudno (wręcz niemożliwe) napisać.

@jarekr000000: problem jest taki, że systemy nie są projektowane pod testowanie tylko przychodzi jeden programista. Zostawi kawałek nietestowalnego gówna, przychodzi następny dorzuci swój kał i tak się tworzy codebase, którego później nie sposób otestować, poszczególne komponenty nie są enkapsulowane, system wywala się w losowych miejscach, trzeba poświęcać masę czasu na czytaniu kału bo programista, który to zostawił to robił leet cody w trakcie pracy, zamiast pracować i teraz szczyci się pracą w FAANGu, a później na siłę próbuje zainteresować innych swoimi wynurzeniami o tym jak jego fekalne praktyki są skuteczne bo doprowadziły go tam gdzie jest. Szkoda tylko, że kosztem innych.

0
twoj_stary_pijany napisał(a):

@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ć.

Najpierw wyluzuj, potem spokojnie czytaj co pisze Twój rozmówca a potem odpisuj bo obecnie odpisujesz zupełnie nie na temat. Odnoś się do tego co piszą inni a nie jedynie do własnych domysłów.
Nigdzie nie pisałem żeby nie testować. Napisałem, że testy jednostkowe To jedynie jeden ze sposobów..
Chyba, że to nie była odpowiedź na moje posty a jedynie chciałeś się podzielić ze mną swoją refleksją... tylko nie wiem po co...

1 użytkowników online, w tym zalogowanych: 0, gości: 1