[massh]

Czemu ludzie nie pisza testow jednostkowych? nie mowiac o unitach czy systemowych czy w ogole stosowaniu TDD. Napisalem w robocie jeden caly modul a potem banda pseudo seniorow nasrala mi tam gownokod na poziomie studenta 1 roku, a drugi gownosenior dal approve na to a potem placz ze maja bugi xD
CI tego nie przepuscilo bo oczywiscie chlopy klapki na oczach i dostali jedno zadanie ktore ma cos tam zrobic a przy tym rozpieprzyli n innych funkcjonalnosci xD no ale ich dziala XD zdalem sobie sprawe ze u mnie malo kto ogarnia napisanie jakiegokolwiek wartosciowego testu. Nasraja tego kodu a potem jak tak nasrane to klasyka w stylu ze hehe dziala to po co ruszac jezcze cos zepsujemy xD #programowanie #gorzkie zale

[Volantie]

@massh ale ze chcesz napisac, ze stworzyli jakas funkcjonalnosc, ktora rozwala inne testy i twierdza ze jest ok? niesly januszez

[massh]

@Volantie: a jak dodam, ze sa zdziwieni ze testy padly bo przeciez ich funkcjonalnosc dziala XD

[massh]

@Volantie: ogolnie 90% ludzi ktorych spotkalem w tej robocie w ogole nie czuje testow, nie widzi sensu ich pisania, nie umie pisac, nie umie korzystac a jak juz cos napisza to sa to turbo gownianej jakosci testy

[LazyInitializationException]

@massh: dziwne. Ja się jeszcze nie spotkałem z tym żeby ktoś testów nie pisał

[massh]

@LazyInitializationException: ale jak to? gdzie tak jest? w moim korpo 99% ludzi tego nie rozumie. Gadam z kolegami z innej roboty to mam wrazenie, ze jest tak samo. Na roznych konferencjach podpytuje firmy o TDD to mowia ze yyy no jak klient chce (czyli jzu wiem ze gowno-kod) xD

moze dodam, ze pracuje w PHP xD Najpierw myslalem, ze to moze wina Magento ale w Symfony taki sam kibel robia na

[Krolik]

@massh: CI nie puściło, więc w czym problem? Niech poprawiają aż do skutku. A przy okazji możesz się dorzucić do CR i dodać parę kąśliwych, ale merytorycznych uwag o jakości kodu.

U nas w firmie dużo złego można powiedzieć o kodzie pisanym przez co niektórych seniorów (zwłaszcza tych wyznających zasadę unikania abstrakcji i podkreślających na każdym kroku jak ważna jest prostota - co sprowadza się u nich do ifologii i zagnieżdżonych

[Jaslanin]

@massh: napisanie testów automatycznych jednostkowych zwykle kosztuje więcej niż napisanie samej funkcjonalności. dla większości klientów jest to niewidoczne i niewartościowe, i jak ktoś im to proponuje, i traktują to jak pytanie w mackdonaldzie o powiększone frytki i kolę, nadmiarowy koszt. Obecnie wiele firm testuje większość rzeczy na produkcji i aktualizuje. Dawniej wszystko było na płycie i nie można było łatwo zaaktulizować więc się lepiej testowało, teraz są aktualizacje przez internet więc

[Krolik]

@Jaslanin: Obecność dobrych testów przyspiesza tworzenie oprogramowania. Tylko trzeba mieć sensownie kod podzielony na moduły, separację odpowiedzialności to wtedy ani nie trzeba mockować / stubować, ani zmiany w kodzie nie rozwalają testów, bo zmieniasz implementacje, a nie interfejsy. Niestety większość ludzi nie umie w projektowanie systemów i problemy z testami to tylko skutek. Nasrają globalnych zmiennych, staticów, cyklicznych zależności, god objects i potem się dziwią, że trzeba mockować. :D

Zaletą testów

[Jaslanin]

@Krolik: dodatkowa praca zawsze spowalnia tworzenie oprogramowania, pisanie testów pomaga utrzymać tępo gdy projekt jest długoterminowy. Problem polega na tym że jak nie pokażesz product ownerowi progresu na początku to w większości zrezygnuje z usług. Mockowania w unit testach nie da się uniknąć ze względu na persystencję. Można to obejść poprzez modelowanie wszystkich danych w obiektach, i wykonywanie wszystkich operacji w pętli na obiektach. Ale taki kod będzie żarł dużo ramu

[mklaudia]

@massh:

Czemu ludzie nie pisza testow jednostkowych? nie mowiac o unitach

to nie to samo?

[massh]

@mklaudia: późno było ( ͡° ͜ʖ ͡°)

[LazyInitializationException]

ale jak to? gdzie tak jest?

@massh: Pracowałem z różnymi językami, java, kotlin, JavaScript, TypeScript. Zawsze testy były. Gdzieś w firmie się używa u mnie PHP i z tego co się orietnuję to testy też są.

[zawadzio]

@massh: bo senior rozwiązuje problem i pyk fakturka, a junior spuszcza się nad kodem xD

[Krolik]

dodatkowa praca zawsze spowalnia tworzenie oprogramowania, pisanie testów pomaga utrzymać tępo gdy projekt jest długoterminowy.

@Jaslanin: Nie, bo szybciej jest napisać test jednostkowy niż przetestować ręcznie, a zwłaszcza przetestować ręcznie kilka razy. Ręcznie będziesz musiał zdeployować rozwiązanie na jakimś środowisku i to zawsze chwilę trwa. Unit test odpala się w kilka ms.
Ale jeżeli oddajesz kod w ogóle *bez testowania* a celem jest napisanie czegoś co nie działa, to tak, pewnie

[Krolik]

bo senior rozwiązuje problem i pyk fakturka, a junior spuszcza się nad kodem xD

@zawadzio: praktyka wygląda tak, że dobry senior robi elegancki kod z testami, który rozwiązuje problem i pyk fakturka, a junior rzeźbi przez tydzień jakiś gówno kod bez testów, po tygodniu ma nasrane tysiące linii pętli, ifów i klas a kod nadal nie działa jak trzeba. I potem przychodzi senior, dopisuje testy w godzinę, wywala 90% tego kodu

[massh]

@Krolik: nic dodac nic ujac.

@zawadzio a potem tacy pierwsi do wysmiewania hindusow a nie jestesie lepsi :D

[tylko_zerknalem]

@Jaslanin:

Mockowania w unit testach nie da się uniknąć ze względu na persystencję.

Oczywiście że można uniknąć. Storage ukrywasz za interfejsem, a w testach jednostkowych implementacja interfejsu operuje na danych w pamięci. Możesz w ten sposób w pełni przetestować swoją logikę biznesową za pomocą testów jednostkowych, nie używając w tym procesie żadnej konkretnej bazy danych. Nawet całe serwery HTTP możesz w ten sposób testować, gdzie Twoja aplikacja to jest blackbox działający

[Jaslanin]

@tylko_zerknalem: to co piszesz to jest literalnie defnicja mocka (obiekt który symuluje inny): https://en.wikipedia.org/wiki/Mock_object#:~:text=Mock%20objects%20have%20the%20same%20interface%20as%20the%20real%20objects%20they%20mimic , więc nie da się uniknąć, to że jest to osobny obiekt który zastępuje inny nie zmienia faktu że symuluje zachowanie innego, i trzeba do tego całą logikę pisać by działało

[zawadzio]

@Krolik: Zgodzę się, jednak takich seniorów ze świecą szukać. Ja niestety spotkałem się z gówno-seniorami, projektami pisanymi na kolanie. Wszystko wygląda tak jak OP pisze, jeden gość wrzuca gównokod, drugi za chwilę daje approve i pyk fakturka :D Problem "rozwiązany" - do najbliższego buga. Jestem deweloperem z przeszłością w testach i jeszcze nigdy nie widziałem dobrych i przemyślanych unitów w korpo :D "Consultant culture" w praktyce.

a potem tacy pierwsi do

[Krolik]

@zawadzio: my zawsze testujemy na prodzie, ale robimy to tak że nie widać (⌐ ͡■ ͜ʖ ͡■)