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.
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ą.
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.