Po co testy jak można przeklikać

2

zależy.

są softy których nie warto testować - są relatywnie małe i/lub mocno zależą na innych systemach, więc pewnie nie będzie nawet czego testować, a postawienie infrastruktury do testów z tym czymś by mogło zająć znaczny % budżetu

10

Możesz użyć argumentu takiego, że podejście z testami manualnymi nie skaluje się razem z przyrostem ficzerów. Im bardziej system będzie rozwijany, tym lawinowo rosną przypadki testowe. A na testy potrzeba czasu, a czas to pieniądz.

Inna sprawa, że nie powinieneś prosić o pozwolenie na pisanie testów - to jest nierozłączna część Twojej profesji. Kod bez testu z założenia nie działa i taki powinien być Twój mindset niezależnie, kto jest w managemencie. Oczywiście pytanie ile masz energii, żeby pomimo trudności robić dobra robotę - IMO nie ma co się szarpać i tak na długa metę się nie rozwiniesz w takim środowisku.

0

Próbowałem tego argumentu ale nie podziadzialo (kontrargument o sprawdzaniu referencji) Chyba nie ma co się szarpać. Infrastruktury pod testy nawet nie ma, pełno staticow wszędzie. Wysiłków i tak nikt nie doceni.

7
  1. Management ma zawsze rację.
  2. Jeśli przedstawisz fakty, wskazujące inaczej to ewidentnie się mylisz i musisz się liczyć z konsekwencjami. Np. zakaz robienia błędów pod karą finansową (przerabiałem ten fragment gry).

Nic nie zrobisz. Spierniczaj - na koniec powiedz co o tym sądzisz. Niewiele to zmieni, ale jak kilku programistów coś takiego powie na odchodnym, to za parę lat okaże się, że management był zwolennikiem automatyzacji testów i tylko programiści, tacy jak Ty, w tym zawsze przeszkadzali.

2

@katakrowa:

się nawet na jego jednokrotne przetestowanie (dosłownie kompiluje się to musi być ok).

Tak przecież powinno być: kompiluje się to musi być ok.
Ale programiści to nieodpowiedzialne lenie i ignoranci, którzy nie potrafią ogarnąć języków z nieco lepszymi kompilatorami i dłubią, jak dziadowie, w podjęzykach, gdzie każdą pierdołę trzeba testować.
(Napisałem każdą, bo obecnie nawet w całkiem zaawansowanych językach i tak "biznes" zwykle trzeba testować, ale wiele rzeczy można jednak odpuścić.)

0

No niby masz racje, ale manager chce wiedziec niekiedy ze dziala, wiec przeklinanie jak nie dziala to troche malo xd

4
nobody01 napisał(a):

Jak byście odbili "argument" o tym, że wystarczy po prostu sprawdzić referencje do metody/zmiennej przed wgraniem commita?

Sprawdzę i co dalej? Mam sobie magicznie wywnioskować kontrakt na postawie wywołań? Domyśleć się jakie warunki ma spełniać metoda? Nawet jak są testy to i tak nie zawsze wiadomo, czemu ktoś podjął takie, a nie inne decyzje. Jednak jeśli jest dobra infrastruktura testowa, to można ewentualnie dopytać się i łatwo dorzucić nowy test.

Jak pracowałem w e-podróżniku jakieś prawie 10 lat temu, to była tam polityka braku testów automatycznych i braku refaktorowania starego kodu. Stary kod już działa, więc nie wolno go zmieniać, bo się jeszcze popsuje. Zwłaszcza kod napisany przez szefa był nietykalny. Trzeba co najwyżej dopisywać nowy kod, który wywołuje stary. Był jeden gość od przeklikiwania wysyłania mejli. Codziennie je generował, sprawdzał swoją skrzynkę i zastanwiał się czy te mejle są dobrze wygenerowane. Mi się udało napisać testy do kodu, który sam pisałem od zera, ale gdy miałem dopisać coś do starego kodu bez infrastruktury testowej, to nie dopisywałem.

W e-podróżniku kilka miesięcy pracowałem nad biletomatem, a konkretnie nad modułem do przyjmowania i wydawania pieniędzy. Ja robiłem moduł w Javie, który:

  • łączył się z czytnikiem kart płatniczych przez TCP/IP - to jakoś dało się ogarnąć sensownie i napisać testy do tego, bo miało specyfikację (i to nawet na tyle dobrą, że testy napisane na jej podstawie wykryły niektóre błędy w programie zanim jeszcze dostałem sprzęt do ręki)
  • łączył się z czytnikiem monet poprzez notorycznie psujący się moduł napisany chyba w Pascalu przez pana Dariusza - sympatycznego gościa w wieku 70+
  • łączył się z czytnikiem banknotów, ale tu już nie pamiętam jak to było - chyba też się psuło, ale rzadziej niż czytnik monet

Niestety integracja z modułem pana Dariusza to była droga przez mękę. Pan Dariusz, mimo iż był sympatyczny, to jednak niereformowalny (nie dziwne, biorąc pod uwagę wiek). Napisał swój badziewny kod naszpikowany globalnym stanem i nie chciał go pokazać (w sensie dopiero jak dał się w końcu namówić to kolega zobaczył ten koszmar w środku). Testów automatycznych to prawdopodobnie nie miało żadnych. Za to ja przez pół dnia stałem przy tym biletomacie, wrzucałem monety i sprawdzałem czy biletomat nie zwariuje, albo czy przynajmniej wyda poprawnie. Podczas tego wrzucania monet sprawdzałem różne scenariusze, w sensie zmieniałem liczbę monet w tubach, by różne z nich się aktywowały. Nieraz udawało mi się "rozbić bank", tzn przy żwawym wrzucaniu monet moduł pana Dariusza głupiał i zaczął wyrzucać wszystkie monety. Opisywałem panu Dariuszowi w jakich scenariuszach jego program głupieje, on po iluś tam dniach przysyłał nową wersję swojego programu (tylko skompilowaną binarkę, bo kodu źródłowego nie chciał dawać), potem ja sprawdzałem, które scenariusze zostały poprawione, a które zepsute, znowu mu raportowałem, on znowu po iluś dniach przysyłał wersję niby poprawioną i tak w koło Macieju. Każdego ranka miałem załamanie psychiczne. Myślałem o tym, że skończyłem studia magisterskie na względnie dobrej uczelni (UJ), podchodzę ambitnie do tematu programowania, a ostatecznie i tak pół dnia wrzucam monety do biletomatu jak jakiś półgłówek.

Powyższa historia w sumie narzuca pewien wniosek - testowanie testowaniu nierówne (albo tester testerowi nierówny), nawet jeśli ograniczamy się do testowania ręcznego. Możliwe, że pan Dariusz testował swój program ręcznie w tempie 70-latka, a bardziej zwinne użycie skutkowało odpaleniem nietestowanych wcześniej interakcji w kodzie. Porządnych stress testów się ręcznie nie zrobi. Pogorszenia wydajności też się często nie wyłapie.

0

Prawie jakbym słyszał pewnego "senior" developera tureckiego pochodzenia, który na linkedin nadał sobie samozwańczy tytuł "Chief Software Architect".

Tyle że u niego ta awersja do testów, to była głównie spodowana tym, że był bardzo słabym programistą i pisał kod niemal niemożliwy do testowania, więc chciał narzucać każdemu swoje zdanie, bo robił w gacie na samą myśl, że sam będzie musiał te testy pisać/utrzymywać.

1

Kontrargument byłby pewnie taki, że jak wiesz, gdzie co jest wykorzystywane, to możesz się przedrzeć przez te wszystkie ify w środku i ogarnąć, co się tam dzieje. :/

5
nobody01 napisał(a):

Kontrargument byłby pewnie taki, że jak wiesz, gdzie co jest wykorzystywane, to możesz się przedrzeć przez te wszystkie ify w środku i ogarnąć, co się tam dzieje. :/

To byłoby równoważne z (w kółko powtarzaną) inżynierią wsteczną. Strata czasu. Testy automatyczne znacznie ograniczają potrzebę czegoś takiego. Oczywiście nie do końca, bo w praktyce testy same w sobie nie są kompletnym odwzorowaniem kontraktu i wszystkich przypadków brzegowych. Gdzieś musi być kompromis - za mało testów źle, ale za dużo kodu testowego to też źle (np. jeśli kodu testowego jest 10x więcej niż produkcyjnego to prawdopodobnie ktoś zbyt mocno zaszalał, no chyba, że projekt jest mocno nietypowy).

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