Czy ktoś poważnie testuje front-end w pracy?

Zwykle testy jednostkowe pisze się do back-endu. Każdy coś słyszał, pokopiuje się i jakoś to działa.
W kwestii front-endu utarło się selenium, które jest nierzadko toporne.
Wielki buzz word a potem wychodzi jak wychodzi, nieustannie podnosi się timeouty jak zadłużenie kraju.
W Angularze są pliki .spec.ts, które się zwykle usuwa. Tester głównie wyłapuje jak coś się rozwali.
Ciężko mi sobie wyobrazić dużą apke bez młynu z warningami i errorami w konsoli.
Cały front-end bywa też tak stabilny jak kwanty w fizyce, jakoś to się trzyma jak się tym nie trzęsie.

Macie jakieś przemyślenia c.d. pisania testow w front-end?

U nas w projekcie frontend traktujemy poważnie i frontendowcy normalnie piszą unit testy do wszystkich, mających jakąkolwiek logikę, komponentów. I te testy są wpięte w pipeline, więc jak coś się kaszani to nawet nie wejdzie do głównego brancha, testy klikające E2E w Playwrite piszą testerzy, tylko one, jak dobrze pamiętam, są już odpalane cyklicznie, co kilka godzin, chociaż jest kilkanaście smoke testów odpalanych po każdym deployu na QA i Prod.
Nie wyobrażam sobie teraz żeby powstawała nowa średnia albo duża aplikacja, w której się olewa jakość frontu, bo nierzadko tam siedzi ponad połowa kodu projektu

Ja testuje, mam niemal 95% pokrycia.

wonman napisał(a):

Zwykle testy jednostkowe pisze się do back-endu.
Każdy coś słyszał, pokopiuje się i jakoś to działa.
W kwestii front-endu utarło się selenium, które jest nierzadko toporne.

Selenium to staruszek.
Obecnie do testów e2e to prędzej Cypress czy Playwright się używa.

W Angularze są pliki .spec.ts, które się zwykle usuwa. Tester głównie wyłapuje jak coś się rozwali.

Niezła patola musi to być XD

Cały front-end bywa też tak stabilny jak kwanty w fizyce, jakoś to się trzyma jak się tym nie trzęsie.
(...)
Ciężko mi sobie wyobrazić dużą apke bez młynu z warningami i errorami w konsoli.

Jeśli za pisanie frontendu odpowiedzialni są backendowcy, którzy piszą testy tylko na backendzie, a na froncie usuwają pliki z testami, to nic dziwnego, że jest potem młyn z errorami w konsoli.

Chociaż też różne patole widziałem. Np. kiedyś pracowałem krótko w firmie, gdzie programiści mieli totalnie wyj*** na testy i czekali tylko na QA. I to mogłoby się obronić, gdyby nie to, że było tam pełno bugów. Bugi, które nawet uniemożliwiały codzienną pracę. Ale programiści mieli totalną wyjebkę i zero własnej inicjatywy i poczucia odpowiedzialności za jakość rozwiązania.

QA oczywiście robiły co mogły i połowa każdego daily to były raporty bugów z różnych krajów - mieliśmy osobne (zlokalizowane pod kątem regulacji itp.) wersje gier na każdy kraj i w każdym kraju były inne bugi. W sumie szybko stamtąd uciekłem, więc już nawet nie bardzo wiem, co robili dalej z tymi bugami. Czy w ogóle ktoś to fiksował.

Moim zdaniem to programiści powinni być pierwszą linią frontu jeśli chodzi o jakość rozwiązania. Pewnie, później może być QA czy feedback od końcowych użytkowników, ale to jednak programista wklepuje ten kod, więc on powinien być osobą, która upewnia się, że wklepała dobry kod, a nie taki, który nie będzie działać.

wonman napisał(a):

Zwykle testy jednostkowe pisze się do back-endu. Każdy coś słyszał, pokopiuje się i jakoś to działa.

Ja piszę testy do każdego kodu jaki piszę. To czy to front czy backend nie ma znaczenia.

wonman napisał(a):

W kwestii front-endu utarło się selenium, które jest nierzadko toporne.
Wielki buzz word a potem wychodzi jak wychodzi, nieustannie podnosi się timeouty jak zadłużenie kraju.
W Angularze są pliki .spec.ts, które się zwykle usuwa. Tester głównie wyłapuje jak coś się rozwali.
Ciężko mi sobie wyobrazić dużą apke bez młynu z warningami i errorami w konsoli.
Cały front-end bywa też tak stabilny jak kwanty w fizyce, jakoś to się trzyma jak się tym nie trzęsie.

No tak to czasem bywa, ale podobne rzeczy w backendzie też występują.

wonman napisał(a):

Macie jakieś przemyślenia c.d. pisania testow w front-end?

Przemyślenie jakie mam, to nie robić z frontu nie wiadomo czego - jakby to było "coś innego" niż backend - nie jest. Front też ma input-process-output tak samo jak backend, trzeba tylko znaleźć odpowiednie miejsca, wydzielić odpowiednie elementy. Wystarczy zidentyfikować ważne miejsca, i zacząć testy od nich

Wystarczy mieć z tyłu głowy zasady TDD: "Nie pisz kodu bez testów", "Najpierw test", test ma sfailować, napisz kod, test ma przejść, powtórz. To nie jest aż takie trudne.

Jedyny powód czemu pisanie testów pod front miałoby być trudniejsze, to to - że jak się czyta dokumentacje jakiegoś reacta czy innego modnego shitu, to tam w dokumentacji testowanie jest zepchnięte na dwudziestą ostatnią stronę, i nikt tego nie czyta. Główne example jakie są to są takie "mały, szybkie' snippety które pokazują jak coś zrobić, ale jednocześnie dodaja bardzo ciasny tight-coupling, przez co testowanie jest trudniejsze.

Niestety, tak - przez followowanie dokumentacji, nasza aplikacja jest trudniejsza do testowania, niestety :/ W wielu miejscach trzeba odejść od dokumentacji żeby dodać takie "dobre praktyki" (ho, ho) jak testy.

W pierwszej pracy frontend był przykryty unitami i pisało się je za każdym razem. W drugiej kazdy miał frontend w dupie, bo to wspaniały crossfunctional team był. Agile

W pierwszym projekcie(Angular) mieliśmy 100% pokrycia testami, jednak po roku góra stwierdziła, że za dużo czasu schodzi na pisanie testów, a za mało na implementację, więc ten procent stale się zmniejsza :D W drugim projekcie nie ma czasu na pisanie testów, bo są chore deadline'y.

wonman napisał(a):

W Angularze są pliki .spec.ts, które się zwykle usuwa. Tester głównie wyłapuje jak coś się rozwali.
Ciężko mi sobie wyobrazić dużą apke bez młynu z warningami i errorami w konsoli.

ok, to jest jakaś ciężka IT patologia

witeks44 napisał(a):

W drugim projekcie nie ma czasu na pisanie testów, bo są chore deadline'y.

Niech zgadnę, nie ma czasu na pisanie testów bo trzeba ciągle łatać bugi?
Taki zapierdol że nie ma kiedy taczki załadować

Wydaje mi się, że tu problem zaczyna się już na wcześniejszym etapie. Tu nawet nie chodzi o to, czy testy są pisane.

Ciężko mi sobie wyobrazić dużą apke bez młynu z warningami i errorami w konsoli.

Tu nawet nie trzeba pisać testów, ale minimum odpowiedzialności - są errory, to je naprawiamy, a nie akceptujemy tej sytuacji jako czegoś normalnego.

Pewnie - pisanie testów to dobry sposób, żeby zapewnić automatyzację wykrywania, czy nie pojawił się jakiś błąd po drodze, ale tutaj mam wrażenie, że zabrakło czegoś więcej (tak jak w moim poście o tym, że ludzie mieli wyj*** na bugi). Testy warto pisać, ale mam wrażenie, że tutaj sedno problemu może nie leżeć w braku testów, a w olewce programistów, z którego wynika wszystko inne.

Mogę się domyślać, że jakość kodu również jest słaba (jeśli ludzie mają wyjebongo) i stąd również pojawiają się nadmiarowe errory, bo apka pewnie jest napisana na kolanie. Dodajmy do tego wspomniany brak testów i mamy obraz całości - słabo napisana i najeżona bugami apka, która nie jest w sensowny sposób otestowana, więc firma utraciła nad nią kontrolę i może co najwyżej stosować taktyki partyzanckie, jeśli chodzi o dalszy rozwój projektu.

W sumie coś w tym chyba jest, bo faktycznie słabi programiści mają tendencje że idą na front (webowe oczywiście :D).

Riddle napisał(a):

W sumie coś w tym chyba jest, bo faktycznie słabi programiści mają tendencje że idą na front (webowe oczywiście :D).

Na froncie faktycznie dużo jest osób o niskim poziomie, dla których architektura kodu, czy myślenie algorytmiczne to czarna magia. Kuleją ogólne umiejętności programistyczne czy wiedza ogólną z programowania (bo nie oszukujmy się - to są ludzie z przypadku często, którzy weszli we frontend bo przeczytali, że to łatwe).

Jednak... jest też druga strona medalu. Nie zapominajmy, że frontendem nie zajmują się tylko pełnoetatowi frontendowcy, ale również backendowcy, którzy są "fullstackami" (bo akurat w projekcie jest Angular, a firmy nie było stać na zatrudnienie frontendowca).

Niestety takie osoby też obniżają jakość projektów frontendowych. Szczególnie jeśli traktuje się frontend jako gorszą część programowania (ten wątek jest tego przykładem, gdzie na backendzie piszą testy, a na frontendzie ich nie piszą. Why?). Ludzie się uczą Angulara czy Reacta, ale nie chce im się uczyć JSa (potem efekt jest taki, że robią sobie kuku, bo taki React wymaga jednak znajomości takich zagadnień jak asynchroniczność w JS), piszą nadmiarowy przeinżynierowany kod, bo nie znają idiomów w JS, tylko piszą JS tak, jakby pisali Javę/C# itp.

Czyli - brak poważnego traktowania frontendu powoduje, że wygląda to jak wygląda (raz, że pełno ludzi z ulicy, dwa że backendowcy klepią frontend i robią to za karę, więc c**** im to wychodzi).

Testy może i są istotne, ale nie zastąpią dobrze zaprojektowanego kodu.
Jak ktoś nie potrafi pisać polimorficznie i jego kod bazuje na setkach ifów, to setki testów tego nie zrekopensują.
To się tyczy backu i frontu.
Także jak ktoś chwali się jak on to stosuje testy, to i tak nie jest to wyznacznik jakości kodu i samej apki.

omenomn2 napisał(a):

Testy może i są istotne, ale nie zastąpią dobrze zaprojektowanego kodu.
Jak ktoś nie potrafi pisać polimorficznie i jego kod bazuje na setkach ifów, to setki testów tego nie zrekopensują.

Niby tak, ale mając dobre testy bardzo ciężko jest napisać taki słaby kod.

omenomn2 napisał(a):

Testy może i są istotne, ale nie zastąpią dobrze zaprojektowanego kodu.
Jak ktoś nie potrafi pisać polimorficznie i jego kod bazuje na setkach ifów, to setki testów tego nie zrekopensują.

Ale testy pomogą w tym, żeby taki kod refaktoryzować.
Poza tym ify są często okej.

W słabym kodzie na ifach nie jest najgorsze to, że są na ifach, tylko to że taki słaby kod może mieć dużo duplikacji, niepotrzebnych zagnieżdżeń, dziwny flow programu. Jak weźmiesz ten kod i przerobisz na obiektowy, to wyjdzie takie samo bagno. Bo to kod nieuporządkowany, niezależnie od tego w jakiej formie się zamanifestuje. Więc nawet refaktoryzacja może nie pomóc.

Jednak mimo wszystko testy są jakimś narzędziem pomagającym myśleć, więc potencjalnie pomogłyby programiście ułożyć sobie lepiej flow. Być może jest tak, jak @Riddle pisze mając dobre testy bardzo ciężko jest napisać taki słaby kod.. Chociaż nie byłbym tego taki pewien.

testy sprawdzają zachowanie danej metody, endpointu w danym przypadku, jeżeli dana metoda obsługuje 10 różnych przypadków zależnych od flag i ifów, to test tutaj nie pomoże, chyba, że napisze się test na każdy jeden przypadek, ale nadal wnętrze metody będzie bagnem, pod kątem czytania, zrozumenia, debugowania i rozwijania.
Ify są konieczne jasne, ale w prostych porównaniach i nie na pewno 10 w jednej metodzie.

omenomn2 napisał(a):

testy sprawdzają zachowanie danej metody, endpointu w danym przypadku, jeżeli dana metoda obsługuje 10 różnych przypadków zależnych od flag i ifów, to test tutaj nie pomoże, chyba, że napisze się test na każdy jeden przypadek, ale nadal wnętrze metody będzie bagnem, pod kątem czytania, zrozumenia, debugowania i rozwijania

To jest trochę nie prawda że testy mają testować metodę.

Testy powinny testować zachowanie programu, nie ważne czy to zachowanie jest w funkcji w klasie czy gdzie. Różdżka programu na podfunkcje to przecież szczegół implementacyjny.

To jest trochę nie prawda że testy mają testować metodę.

Testy powinny testować zachowanie programu, nie ważne czy to zachowanie jest w funkcji w klasie czy gdzie. Różdżka programu na podfunkcje to przecież szczegół implementacyjny.

Program jest zawsze w metodzie, klasy korzystają z metod, ale można napisać metodę (funkcje inaczej) poza klasą, można też napisać skrypt, który też będzie korzystał z metod, więc pisząc testy przeważnie testuje się metodę lub endpoint lub skrypt jak już musimy być tacy precyzyjni.
Skupiasz się trochę, na mniej istotnej części mojej wypowiedzi, w której chodzi o to, że jak napiszesz metodę na 1000 linijek z 50cioma ifami, flagami w parametrach, to testy takiego kodu nie uratują i tak czy siak będzie to bagno.
Jeżeli ktoś tak pisze, ale za to stosuje testy to i tak nie jest dobrym programistą i nie pisze dobrego kodu.

ja unit testow na fe no robie ale staram sie sam jak najwiecej ich wylapywac, testowac moje aplikacje i pisac kod conajmniej "przyzwoity"
QA swoja droga robia e2e test & acceptance test & regression test + testujemy input/output naszych api wiec duzo rzeyczy jest wylapywanych zanim dojdzie do produkcji, poki co nigdy nam sie nie zdarzylo zeby byly jakies wieksze bugi (nie znane nam tzn nie sa w backlogu) na produckji