W Facebooku nie piszą testów

N0
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:Gdańsk
  • Postów:647
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

TS
  • Rejestracja:ponad 5 lat
  • Ostatnio:około 2 godziny
  • Postów:851
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.

edytowany 1x, ostatnio: twoj_stary_pijany
SM
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
katakrowa
  • Rejestracja:prawie 10 lat
  • Ostatnio:prawie 2 lata
  • Lokalizacja:Chorzów
  • Postów:1670
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.


Projektowanie i programowanie. Hobbystycznie elektronika i audio oszołom.
ZT
ZT
  • Rejestracja:około 6 lat
  • Ostatnio:ponad 2 lata
  • Postów:102
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.

somekind
A czego mBank nie testuje?
TS
  • Rejestracja:ponad 5 lat
  • Ostatnio:około 2 godziny
  • Postów:851
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.

edytowany 3x, ostatnio: twoj_stary_pijany
SL
  • Rejestracja:prawie 7 lat
  • Ostatnio:5 minut
  • Postów:828
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
edytowany 2x, ostatnio: slsy
katakrowa
Zgadzam się z Tobą jednak Większość pisze jedynie CRUDY do lokalnego API i oceniają to przez taki pryzmat. Z takiej perspektywy faktycznie testy są "złotem". Ja jednak częściej piszę dziwactwa na skraju systemów lub integracji z zewnętrznymi źródłami często słabej jakości ale zawierające złożone struktury danych i w tym obszarze pisanie testów to zwykła strata czasu.
piotrpo
  • Rejestracja:ponad 7 lat
  • Ostatnio:3 minuty
  • Postów:3265
1

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

N0
Ten tweet jest w odpowiedzi na tweet o kimś kto pracował przy iosie w FB i też się zbytnio nie przejmował testami.
lion137
  • Rejestracja:prawie 8 lat
  • Ostatnio:11 minut
  • Postów:4805
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.


edytowany 1x, ostatnio: lion137
Schadoow
  • Rejestracja:około 13 lat
  • Ostatnio:15 minut
  • Postów:1056
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.

edytowany 1x, ostatnio: Schadoow
katakrowa
  • Rejestracja:prawie 10 lat
  • Ostatnio:prawie 2 lata
  • Lokalizacja:Chorzów
  • Postów:1670
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.


Projektowanie i programowanie. Hobbystycznie elektronika i audio oszołom.
edytowany 3x, ostatnio: katakrowa
WeiXiao
  • Rejestracja:prawie 9 lat
  • Ostatnio:2 minuty
  • Postów:5049
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

edytowany 5x, ostatnio: WeiXiao
N0
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:Gdańsk
  • Postów:647
0
N0
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:Gdańsk
  • Postów:647
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?

edytowany 4x, ostatnio: nobody01
SA
  • Rejestracja:około 12 lat
  • Ostatnio:33 minuty
  • Postów:1410
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.

Riddle
Moderator Inżynieria oprog.
  • Rejestracja:ponad 14 lat
  • Ostatnio:4 minuty
  • Lokalizacja:Laska, z Polski
  • Postów:9965
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.

S9
  • Rejestracja:około 4 lata
  • Ostatnio:około 2 lata
  • Lokalizacja:Warszawa
  • Postów:1092
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


edytowany 1x, ostatnio: scibi_92
opiszon
Wieki temu pracowałem dla klienta ze Szwajcarii który zabudżetował tylko kody, bez testów i bez bugfixingu ponieważ cytuję "jestescie jak Harry Potterzy programowania i napiszecie kod bezbłednie". I potem był zdziwiony że dowieziona na czas aplikacja nie działała jak trzeba. Swoją drogą nie rozumiem dlaczego wykonawca zaakceptował projekt który z góry krzyczał ze jest niedoszacowany i nie da się go zrobić w założonym czasie. No ale może taki był plan od początku...
jarekr000000
Gwoli ścisłości - akurat zakaz robienia bugów to miałem w czysto polskiej firmie - bez niemców.
katakrowa
  • Rejestracja:prawie 10 lat
  • Ostatnio:prawie 2 lata
  • Lokalizacja:Chorzów
  • Postów:1670
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.


Projektowanie i programowanie. Hobbystycznie elektronika i audio oszołom.
Riddle
Moderator Inżynieria oprog.
  • Rejestracja:ponad 14 lat
  • Ostatnio:4 minuty
  • Lokalizacja:Laska, z Polski
  • Postów:9965
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).

edytowany 2x, ostatnio: Riddle
Zobacz pozostałe 21 komentarzy
Riddle
Couldn't care less "dyskusją" z Tobą. Ale testy testami, nie jest łatwo jest pisać, i jest masa ludzi, którzy mają podobny pogląd jak Ty" "tego się nie da przetestować", "tamtego się nie da", o rzeczach które całkowicie się da przetestować, jeśli tylko się wie jak.
katakrowa
@Riddle pogląd jak Ty" "tego się nie da przetestować" - gdzie to napisałem? Jak masz jaja to napisz jak! Nie wracaj do początku rozmowy bo to nie ma sensu. Dałem Ci konkretny przykład i konkretne założenia. Jesteś pewien, że się da to wskaż jakieś rozwiązanie, które jest uzasadnione ekonomicznie i czasowo. Ja nigdzie nie napisałem, że się nie da a Ty ciągle to powtarzasz. Uważam, że nie ma najmniejszego sensu i nie warto a to jest różnica. Wszystko się da. Tylko po co skoro manualne testowanie będzie tu 1000 razy lepsze.
Riddle
No, nie zawsze. Raz napisany test automatyczny zostaje w aplikacji, testowanie manualne zabiera czas z każdym razem jak chcesz je "uruchomić". Jak masz jaja to napisz jak! To nie jest takie proste, bo trzeba siedzieć w projekcie w którym piszesz testy, ale prawie zawsze opłaca się pisać automaty zamiast testować manualnie. Jeśli projekt żyje powiedzmy pół roku albo dłużej, to już się opłaca.
katakrowa
Jedyne z czym się mogę zgodzić to z prawie zawsze jednak są przypadki, że się nie opłaca i nie ma to sensu. Napisałem to w poście powyżej: W Facebooku nie piszą testów
Riddle
A ja dodam że prawie zawsze na pierwszy rzut oka się nie opłaca, ale jak się pomyśli, to z każdym kolejną godziną zwaste'owaną na manuale się opłaca coraz bardziej.
W0
  • Rejestracja:ponad 12 lat
  • Ostatnio:około godziny
  • Postów:3460
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.

Sensacyjny Sebastian
  • Rejestracja:ponad 5 lat
  • Ostatnio:13 minut
  • Postów:377
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.

WeiXiao
Facebook przez długie lata był napisany w PHP, a jak powszechnie wiadomo, od znajdowania bugów w PHP nie jest kompilator, tylko klient. :D
SA
  • Rejestracja:około 12 lat
  • Ostatnio:33 minuty
  • Postów:1410
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 🙃

katakrowa
Jeśli jesteś tego pewien to zajrzyj do komentarzy w poście: W Facebooku nie piszą testów
WeiXiao
@Saalin: Jeśli człowiek jest w stanie ocenić czy coś działa poprawnie to można napisać kod computer vision chciałaby pewnie z tobą podyskutować na ten temat
Schadoow
  • Rejestracja:około 13 lat
  • Ostatnio:15 minut
  • Postów:1056
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.

TS
  • Rejestracja:ponad 5 lat
  • Ostatnio:około 2 godziny
  • Postów:851
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.

edytowany 1x, ostatnio: twoj_stary_pijany
SE
AI z 22 wcale nie jest taki zly. Szczegolnie jezeli mowimy o poznej fazie turnieju lub gdy Twoj stack wynosi < 10BB. To samo w poznej fazie do stealu blindow, zakladajac ze przeciwnik jest loose i moze callowac z A high czy K high.
TS
Masz rację. Powinienem dodać, że przy 7 osobach przystole oraz na UTG.
jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:około godziny
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4699
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).


jeden i pół terabajta powinno wystarczyć każdemu
edytowany 2x, ostatnio: jarekr000000
Zobacz pozostałe 2 komentarze
Schadoow
mhm nie no wersjowanie to juz nawet standard wśród starych niemieckich programistów/architektów :p
jarekr000000
@Schadoow: to prawda to już standard, ale mocarne zespoły, które "radzą sobie" bez tego nadal spotkasz.
Schadoow
Na razie spotkałem w jednym systemie "własny system do wersjonowania", (nie zdziwiłbym sie jakby początki były starsze niz ja) i tam maja migracyjne skrypty bashowe.
SW
Nawet skrypty, które robią curle/bashe/pythony naprawiające/migrujące/insertujące da się testować i to się robi (przynajmniej u mnie w zespole się robi)
R7
@jarekr000000: Jakie wersjonowanie bazy danych masz na myśli? W sensie co tam ma być wersjonowane, całość bazy czy poszczególne obiekty w niej?
Schadoow
  • Rejestracja:około 13 lat
  • Ostatnio:15 minut
  • Postów:1056
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.

edytowany 3x, ostatnio: Schadoow
several
  • Rejestracja:ponad 15 lat
  • Ostatnio:około 5 godzin
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).


N0
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:Gdańsk
  • Postów:647
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.

KA
  • Rejestracja:ponad 10 lat
  • Ostatnio:około 2 lata
  • Postów:594
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

edytowany 1x, ostatnio: karsa
TS
  • Rejestracja:ponad 5 lat
  • Ostatnio:około 2 godziny
  • Postów:851
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.

edytowany 2x, ostatnio: twoj_stary_pijany
SM
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ąć. Takich ludzi należy yebac bo to debile, bo o ile można powiedzieć że już kończe jeszcze tylko testy zostały, to powyższy dialog nie jest normalny i trzeba wyjaśnić takiej osobie żeby się uspokoiła albo coś.
katakrowa
  • Rejestracja:prawie 10 lat
  • Ostatnio:prawie 2 lata
  • Lokalizacja:Chorzów
  • Postów:1670
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...


Projektowanie i programowanie. Hobbystycznie elektronika i audio oszołom.
edytowany 1x, ostatnio: katakrowa

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.