Po co komu testy jak można przeklikać po wprowadzeniu zmian. Dobry programista potrafi sprawdzić, czy kod, który dodał, nie psuje niczego w systemie. /s
Jakie kontrargumenty byście dali w takiej sytuacji....?
EDIT: dla pewności: to wyżej to był sarkazm, ale słowa są z prawdziwej dyskusji kilka dni temu :P
Po co przeklikiwać, skoro można mieć testy? ;-)
Po co w ogóle kod jak ktoś może ręcznie wykonywać wszystkie operacje?
Można tak wprowadzać zmiany, żeby niczego nie zepsuć.
Tak na serio to jest to dużo prawdziwszy cytat niż się wydaje. Zauważyłem, że wraz z wzrostem umiejętności coraz łatwiej jest spojrzeć na kod i określić, gdzie są możliwe problemy. Co oczywiście nie znaczy, że testów nie należy pisać.
Odpowiedzi:
po co ręcznie skoro można patykiem na piasku to narysować? :)
Jak masz proste crudy to raczej nie będzie problemu, jednak gdy masz skomplikowany system np magazynowo księgowy to życzę ci powodzenia w przeklikiwaniu.
Regresja. Dodajesz feature A w jednej części systemu/mikroservisu a sypie się coś innego, a nie dodawana funkcjonalność. Jak zmieniasz wewnętrze commonsy/utilsy to musisz przeklikać całą aplikację. Podobnie przy upgrade jezyka lub częściej używanej biblioteki
Dobry programista potrafi sprawdzić, czy kod, który dodał, nie psuje niczego w systemie
Jaką masz pewność że wszyscy zespole są dobrzy? Jaką masz pewność że nikt nie jest na kacu? Albo nie ma migreny zabójcy?
nobody01 napisał(a):
Po co komu testy jak można przeklikać po wprowadzeniu zmian.
W systemie typu popierdółka z 10-20 formatkami pewnie się da.
Ale płacić programiście za klikanie po systemie, ponieważ wprowadził zmianę, jest ekonomicznie nieefektywne.
A tego kto to zlecił w firmie, które jest spółką prawa handlowego, można pociągnąć do odpowiedzialności karnej z tytułu narażenia firmy na straty finansowe; więzienie od 3 mieś w górę.
A co! :)
Dobry programista potrafi sprawdzić, czy kod, który dodał, nie psuje niczego w systemie. /s
Tylko gdzie ich znaleźć, tych dobrych programistów?
To bzdura, w każdym bardziej złożonym systemie to fizycznie niemożliwe.
Jakie kontrargumenty byście dali w takiej sytuacji....?
Spiexxxxam z tego bajzlu.
wartek01 napisał(a):
Odpowiedzi:
- Testy są szybsze niż klikanie.
Ale tak naprawdę testy testują poszczególne funkcjonalność i a nie całe działanie systemu. Przeklikać i tak należy
- Pisanie testów wspiera proces projektowania kodu.
W niektórych przypadkach go utrudnia.
- Programista to człowiek i popełnia błędy, automat nie.
No ale te automaty stworzył ułomny człowiek. Czyli też są narażone na błędy.
@UglyMan:
Ale tak naprawdę testy testują poszczególne funkcjonalność i a nie całe działanie systemu. Przeklikać i tak należy
Dlaczego należy?
Ja nie przeklikowywuje tylko jeb push i na produkcję (serio często to robię). Oczywiście, raz na jakiś czas wydarza mi się jakieś rozczarowanie, ale nie na tyle czesto, żeby się tym przejmować.
@nobody01
Dobry programista potrafi sprawdzić, czy kod, który dodał, nie psuje niczego w systemie. /s
to niech sprawdza. Ja tam nie jestem dobrym programistą - nie chce mi się klikać.
Pamiętaj, jak się kompiluje to testować nie trzeba, przecież działa
jarekr000000 napisał(a):
@UglyMan:
Ja nie przeklikowywuje tylko jeb push i na produkcję (serio często to robię). Oczywiście, raz na jakiś czas wydarza mi się jakieś rozczarowanie, ale nie na tyle czesto, żeby się tym przejmować.
Wszystko zależy od systemu, człowieka i testów. Parę razy zdarzyło mi się zepsuć produkcję, bo zaufałem testem - jednstkowym, integracyjnym wydajnościowym - za bardzo.
Burdzi0 napisał(a):
Pamiętaj, jak się kompiluje to testować nie trzeba, przecież działa
No chyba, że to PHP albo python
KamilAdam napisał(a):
Jak zmieniasz wewnętrze commonsy/utilsy to musisz przeklikać całą aplikacę. Podobnie przy upgrade jezyka lub częściej używanej biblioteki
Eee tam, to wystarczy po prostu z rozwagą te zmiany wprowadzać (też prawdziwe słowa). xd
W sumie to tydzień temu sypła się produkcja przez moje zmiany i zarzucono mi, że po prostu jestem słabym programistą. Bo przecież dobry programistą zna całą domenę na wylot i jeszcze przed uruchomieniem wie, czy będzie działać. A to że system nie ma żadnej dokumentacji ani testów to przecież nie problem, w kod wystarczy spojrzeć i wszystko wiadomo. /s
nobody01 napisał(a):
Po co komu testy jak można przeklikać po wprowadzeniu zmian. Dobry programista potrafi sprawdzić, czy kod, który dodał, nie psuje niczego w systemie. /s
Samodzielnie przeklikać to teoretycznie można swoje zmiany w swoim kodzie, ale sprawa komplikuje się, gdy zmieniasz kod napisany przez kogoś innego. Wtedy (dla pewności) musisz zapytać autora oryginalnego kodu o to co należy przeklikać. Jeśli zdążył już zmienić pracę, no to peszek :/
Burdzi0 napisał(a):
Pamiętaj, jak się kompiluje to testować nie trzeba, przecież działa
W językach silnie (bardzo silnie) typowanych to jest całkiem bliskie prawdy. :)
To dwa poziomy testowania przecież.
Programiści mogą sobie napisać unit testy, ale nie zastąpi to przeklikania. I to też nie tylko przez programistę, ale też przez prawdziwego człowieka, użytkownika. Ogólnie software jest najmocniej testowany na produkcji przez użytkowników końcowych.
Nie znaczy to, że pisanie testów jest niepotrzebne, po prostu testy "pisane" sprawdzają, czy system działa, tak jak ma działać.
I to jest ważne (żeby wiedzieć, czy dobrze robimy, czy nie ma regresji itp.), jednak problem w tym, że to nie wystarczy. Użytkownicy potrafią zepsuć każdy system, bo użytkownik nie wie, jak system ma działać wg autorów. Jest taki dowcip:
https://twitter.com/brenankeller/status/1068615953989087232?lang=en
Dobry programista potrafi sprawdzić, czy kod, który dodał, nie psuje niczego w systemie.
Nawet jeśli, to czemu programista ma tracić czas na to, skoro można napisać i samo będzie się sprawdzało.
Swoją drogą to zdanie typu "dobry chirurg nie musi myć rąk, zakładać rękawiczek itp., bo będzie potrafił tak operować, żeby niczego nie dotknąć"...
Dobry programista potrafi sprawdzić, czy kod, który dodał, nie psuje niczego w systemie.
Dobry koń to i po błocie przejdzie
Jak byście odbili "argument" o tym, że wystarczy po prostu sprawdzić referencje do metody/zmiennej przed wgraniem commita?
Ale Ty na serio nie wiesz i się pytasz o takie rzeczy na forum, czy bekę kręcisz?
? Szukam argumentów, które przekonają nie mnie, a kogoś innego, kto jest uparty w takich przekonaniach jak wyżej.
Ale nie przekonasz logicznym argumentem osoby, która jest uparta w swoich poglądach. Łatwiej będzie zmienić firmę.
nobody01 napisał(a):
? Szukam argumentów, które przekonają nie mnie, a kogoś innego, kto jest uparty w takich przekonaniach jak wyżej.
Ale musisz z tą osobą pracować? Czy nie chcesz się rozstać z innych powodów? Bo nikt normalny (w sensie: racjonalny) nie będzie klikał, jeśli można puścić program/skrypt, który zrobi to szybciej, lepiej, z większym pokryciem i który można puścić od nowa po każdej, najdrobniejszej zmianie...
To management ma takie poglądy. Ogólnie wydaje im się że dobry programista nie potrzebuje testów.
nobody01 napisał(a):
To management ma takie poglądy.
Rozumiem. Więc pewnie ich nie przekonasz. :) Dobrze przynajmniej płacą za takie szkodliwe warunki? :) Bo jak nie, to może warto przemyśleć zmianę.
Skoro robię bledy, to nie jestem dobrym programista, więc dobrze nie płacą. :) Pewnie przy jakiejś rozmowie o podwyżce zostałoby to wyciągnięte jako argument przeciw.
Jak wyżej - szkoda strzępić ryja, rzuciłbym papierem. Serio.
nobody01 napisał(a):
Skoro robię bledy, to nie jestem dobrym programista, więc dobrze nie płacą. :) Pewnie przy jakiejś rozmowie o podwyżce zostałoby to wyciągnięte jako argument przeciw.
Widzę, że to jakiś toksyczny związek. :) Może znajdziesz coś lepszego?
Testy to jedynie narzędzie ułatwiające i nieco automatyzujące pracę ale jedynie w pewnym zakresie. Póki co nie zastąpią ani zdrowego rozsądku ani dobrego testera, który potrafi sprawdzić głębsze zależności w systemie niż "oczekiwany rezultat funkcji". Na pewnym poziomie i przy pewnej skali projektów są standardem co zdecydowanie popieram bo programiści to nieodpowiedzialne lenie i ignoranci, którzy potrafią wrzucać do repozytorium całkowicie skopany kod nie wysilając się nawet na jego jednokrotne przetestowanie (dosłownie kompiluje się to musi być ok).
Faktem jest też to, że kiedyś testów automatycznych nie było a bardzo dobre aplikacje powstawały. Dziś także nie każdy pisze testy bo nie zawsze ma to sens.
Branża programistyczna ma już swoje lata i zdążyła wypracować masę alternatywnych metod, które w procesie tworzenia i wdrażania oprogramowania są równie skuteczne w wyłapywaniu błędów.
Być może to jedynie moje odczucie ale uważam, że kiedyś programiści więcej uwagi przykładali do tego co spod ich łapy wychodzi.. Teraz króluje podejście "napisałem zrobione i ch...j idę do domu niech inni się martwią jak coś jest źle najwyżej po weekendzie będzie ticket żeby poprawić". Dlatego właśnie wynikła potrzeba testowania tych "elementarnych" składników systemu.
Po prostu nie można ufać programistom i trzeba zakładać, że mogą spier.....ić nawet najmniejszy i najprostszy fragment kodu.