O testowaniu dla programistów

Testy na frontendzie – hit czy kit?

Kiedy słucham programistów skupiających się na pisaniu frontendowej części aplikacji, często słyszę, że nie ma miejsca na testy. Unity i testy integracyjne piszą backendowcy, testerzy piszą e2e i testują manualnie. Na frontnedzie nie ma logiki, więc nie ma potrzeby pisania testów. Czy na pewno? Ja co prawda wywodzę się raczej z backendowych czeluści, ale pisanie frontedów też nie jest mi obce. Nie cierpię na frontendowstręt (jak to ktoś ładnie określił) jak wielu backendowców. Jeśli obserwujesz u siebie takie objawy, przeczytaj ten wpis Andrzeja Krzywdy. Nawet jeśli nie zamierzasz być full stackiem, to warto czasem spojrzeć trochę dalej niż własne podwórko, Czytaj dalej…

Przez Ola Kunysz, temu

Nie możesz pisać testów zawsze? Pamiętaj chociaż o tych trzech sytuacjach

Nawet ja rozumiem, że nie zawsze da się pisać testy. To znaczy, tak byłoby najlepiej, ale życie nie zawsze jest takie kolorowe. Przez sytuację w projekcie albo swoje umiejętności czasem może być trudno. Wtedy zadaj sobie pytanie, czy nie jesteś w jednej z tych sytuacji:   1. Musisz się „bronić” przed innymi zespołami. Jeśli pracujesz w większym projekcie to na pewno są takie części systemu, które wpływają na Twój kod. Jeśli go nie zabezpieczysz przed niechcianymi zmianami, szybko możesz ponieść konsekwencje cudzych działań. Możesz wykorzystać testy kontraktowe, albo inne testy integracyjne, które będą stały na straży.   2. Nie rozumiesz Czytaj dalej…

Przez Ola Kunysz, temu

Dlaczego możesz nie chcieć robić pull request’ów?

Pull request zagościł na dobre w większości projektów. Bez względu na to, czy chcemy wykorzystać go do code review, czy do bezpiecznego wchodzenia na produkcję, stał się narzędziem, które ciężko zastąpić. Czy to jednak nie spowodowało, że trochę go nadużywamy? Osobiście mam dobre doświadczenia z PR’ami, ale znam wiele osób, które chętnie pozbyły by się ze swojego procesu. Tylko co wprowadzić w zamian? Ostatnio na Clubhouse zorganizowałam dyskusję na temat pull requestów i muszę przyznać, że doświadczenia są bardzo różnorodne. Od juniorów, którzy nie znają innej rzeczywistości, przez programistów widzących wady i zalety, po tych którzy pozbyli się zupełnie PR’ów Czytaj dalej…

Przez Ola Kunysz, temu

Ludzie Testowania 2020 – jest podium 💥

W grudniu odbyło się głosowanie Ludzie Testowania 2020 organizowane przez portal testerzy.pl. Portal zajmuje się szerzeniem wiedzy na temat testów automatycznych i innych tematów przydatnych w pracy QA. Sama często korzystam z ich materiałów kiedy potrzebuję testerskiej perspektywy. Tym większa była moja radość z powodu tej nominacji, że jestem programistką. Zajmuję się głównie testami jednostkowymi i integracyjnymi. Nie tylko na tym blogu, ale też na YouTubie, Instagramie i cotygodniowym newsletterze. Moim celem od początku prowadzenia Szkoły Testów było zacieranie granic pomiędzy testerami i programistami. Za jakość odpowiadamy wszyscy, mimo, że w trochę inny sposób. Ta nominacja jest najlepszym dowodem na Czytaj dalej…

Przez Ola Kunysz, temu

Jak mierzyć jakość testów? Line coverage, branch coverage i testy mutacyjne

Do mierzenia jakości kodu stosujemy różne metryki, od złożoności (cyclomatic complexity), przez ilość błędów na produkcji, po dług techniczny (technical dept). Wiele zespołów dodało do tego również miarę pokrycia kodu testami (code coverage). Z tym podejście wiąże się jednak ryzyko, że testy będą pisane głównie po to, żeby pokrywały więcej linijek kodu, a nie żeby dobrze chroniły przed regresją. To może oznaczać to samo, ale wcale nie musi. Mówi się, że rośnie to, co mierzymy. Jeśli mierzymy procent linijek kodu, dla których istnieje kod testowy, który je wywołuje, to urośnie nam liczba testów. To niekoniecznie musi iść w parze z jakością Czytaj dalej…

Przez Ola Kunysz, temu

Co jest nie tak z tym testem?

Testy podobnie jak kod produkcyjny ewoluują. Zmieniają się w czasie. Czasem to dobra zmiana, a czasem niekoniecznie. Wtedy nabierają złego zapachu. Phoebe z Friends’ów śpiewała kiedyś Smelly Cat, Smelly Cat, it’s not your fault, równie dobrze mogłaby zaśpiewać Smelly Test, Smelly Test, it’s not your fault. To nie wina testu, że coś się z nim dzieje, tylko ignorancji zespołu projektowego, który przechodzi obojętnie udając, że wszystko jest ok. Postanowiłam wziąć na warsztat testy, które nie pachną dobrze, żeby pokazać jak małymi krokami można dojść do całkiem niezłych efektów. Weźmy na przykład taki test: @Test void shouldReturnOne() {     int Czytaj dalej…

Przez Ola Kunysz, temu