przemuh.dev [PL]

Krótka historia o optymalizacji

Sun, 08 Nov 2020 00:00:00 GMT

Jakiś czas temu na Twitterze zamieściłem zrzut ekranu pokazujący flame-chart z narzędzia Profiler. Pracowałem wtedy nad poprawą wydajności aplikacji, którą rozwijamy w Egnyte. Pewna funkcjonalność, dla dużej ilości danych, zajmowała strasznie dużo czasu - 3,5 minuty! Przez ten czas w aplikacji pokazywany był "kręciołek", a użytkownik nie wiedział, czy coś się dzieje, czy może coś się zawiesiło. Po kilku dniach pracy z Profilerem udało mi się zaimplementować poprawki, które zredukowały czas potrzebny do obliczeń z 3,5 minuty do 35 sekund. W tym wpisie chciałbym opisać jak do tego doszedłem.

Opis funkcjonalności

Zacznijmy od opisu funkcjonalności, która krótko mówiąc kulała pod względem wydajności. Jednym z głównych widoków w naszej apce jest tzw. "Sensitive Content". Pokazujemy tu listę folderów z plikami, które zawierają wrażliwe dane. To mogą być numery kart kredytowych, dane medyczne, personalne i nie tylko. Dane te mogą podchodzić pod jedną z kilkunastu wbudowanych polityk np. HIPA, GDPR, ale również dajemy możliwość użytkownikom zdefiniowana własnej polityki np. w oparciu o utworzony wcześniej słownik. Początkowo widok "Sensitive Content" pokazywał tylko płaską listę folderów. W zeszłym roku nasz Product Owner wraz z zespołem UX doszli do wniosku, że praca z płaską listą folderów może być nieefektywna. Zamiast tego dużo lepszym, i w zasadzie bardziej naturalnym sposobem reprezentacji danych, będzie drzewko folderów.

Widok Sensitive Content List

Algorytm budowania drzewa

Podejść do drzewek było już u nas w projekcie kilka. Głównie opierały się one na własności folderu jakim było unikalne folderId. Niestety, w przypadku "Sensitive Content" nie mogliśmy tego użyć, ponieważ nie wszystkie foldery mogły zawierać wrażliwe dane, a tylko dla takich folderów dostawaliśmy folderId.

/Shared/A/B/

W tym wypadku mamy 3 foldery (Shared, A, B), z czego tylko dla B dostajemy folderId

Takich lokacji z SC (Sensitive Content) może być multum. Problem wydajności pojawiał się już przy 250 tysiącach lokacji. A że nie jest to wyjątek utwierdził nas klient, u którego znaleźliśmy prawie milion folderów. To właśnie dla 1M elementów listy, czas budowania drzewka wynosił 3,5 minuty. Dlatego też, moje zadanie polegało na tym, że drzewko dla 1M elementów ma się budować w mniej niż 60s.

Wracając do algorytmu. Prosty - jak budowa cepa - tak by się wydawało :)

Weź całą ścieżkę i podziel ją na fragmenty wg. separatora np. /
Każdy folder wsadź do dwóch struktur: "drzewiastej" i "płaskiej"
Jeśli folder nie ma folderId traktuj go jako meta-folder

Dla uproszczenia pomijam kwestię tego, że wspieramy różne źródła danych i te separatory mogą się mocno różnić :) Co więcej, jak się później okazało, niektóre źródła danych mogą mieć dwa foldery o tej samej nazwie, na tym samym poziomie zagnieżdżenia 😱. I jak je rozróżnić? Pominę też kwestię tego, że wynikowe drzewo mieliśmy przedstawić w formie "sparse-tree". W skrócie - chodzi o to, że jeśli folder zawiera tylko jeden sub-folder, to ścieżka rodzica powinna być zwinięta/scalona.

Lista:

/Shared/A/B/C
/Shared/A/B/D

-->
Drzewo:

/Shared/A/B
    /C
    /D

Pierwsza, a w zasadzie druga implementacja

Jak już wspomniałem wcześniej, nie było to pierwsze drzewo, jakie mieliśmy wyświetlić w aplikacji. W zupełnie innym widoku, też mieliśmy zrobić sparse-tree i nie chcieliśmy mieć kilku różnych implementacji. Dlatego napisaliśmy prosty moduł do budowania i zarządzania drzewkiem. Oparty został o dwa małe komponenty:

funkcję buildTree, która przyjmowała płaską tablicę węzłów i miejsce (ścieżkę w drzewie) od którego miała te węzły wstawiać
"plasterek" (slice) z redux-toolkit, który zarządzał strukturą drzewa (rozwijanie, zwijanie węzłów itp.)

Całe drzewo, a w zasadzie te dwie struktury "drzewiasta" i "płaska", trzymane były w reduxie w następujący sposób:

{
    tree: {
        path: "", // root
        children: {
            "Shared": { // path-part or folder name as a key
                path: "/Shared",
                children: {
                    "A": {
                        path: "/Shared/A",
                        children: {}
                    }
                }
            }
        }
    },

    paths: {
        "/Shared": {
            meta: true,
            ...nodeProps
        }
        "/Shared/A": {
            meta: false,
            folderId: "some-unique-id",
            ...nodeProps
        }
    }
}

Taką strukturę otrzymujemy z pomocniczej funkcji buildTree.

Dzięki zastosowaniu redux-toolkit, a co za tym idzie biblioteki immer, mogliśmy w bardzo prosty sposób wykonywać operacje na drzewie:

const initialTreeState = {
  initialized: false,
  tree: {
    path: "",
    children: {},
  },
  paths: {},
}

export const createTreeSlice = treeName =>
  createSlice({
    name: treeName,
    initialState: initialTreeState,
    reducers: {
      insertTree: ({ tree, paths }, { payload }) => {
        paths = {
          ...paths,
          ...payload.paths,
        }
        const node = getNodeByPath(payload.parentPath || "", tree)
        node.children = payload.tree.children
      },

      toggleNode: ({ tree }, { payload: path }) => {
        const node = getNodeByPath(path, tree)
        node.expanded = !node.expanded
      },
    },
  })

Pomocnicza funkcja getNodeByPath służy do wyszukiwania węzła po ścieżce. Potrafi też wyszukać węzeł w sparse-tree.

Pierwsze podejścia do optymalizacji i pierwsze błędy

No i wszystko pięknie-ładnie, ale przyszedł klient, 1 milion folderów i jebs... Product Owner zakłada Epic w Jirze pt. "Support 1M folders on SC tree view". Szybka burza mózgów i od razu kosz pełen pomysłów:

a może by tak budować drzewo w locie, jak parsujemy JSONa?
a może by tak budować drzewo w web-workerze, przynajmniej nie zablokujemy głównego wątku na 3,5 minuty?
a może by tak, pizgnąć to wszystko i wyjechać w Bieszczady? ⛰ 🐑

Pierwszy błąd - nikt nawet nie odpalił Profilera, żeby zobaczyć co zajmuje tyle czasu. Każdy założył, że obecna implementacja drzewka wymiata i lepiej być nie może. Sam Profiler na pierwszy rzut oka nie jest prostym narzędziem i może to było powodem tego, że rzuciliśmy się wtedy na tego typu pomysły jak budowanie drzewa "w locie" czy przeniesienie tego do web-workera. Warto też podkreślić, że sam Epic w Jirze powstał już jakiś czas temu, a do samej implementacji usiadłem w połowie października.

Pewnie zastanawiacie się - ale jak to w locie? Przecież jak idzie request to dopiero jak przyjdzie odpowiedź to przeglądarka parsuje JSONa i daje odpowiedź. Tak, ale...w tym przypadku nasi backendowcy też musieli podziałać trochę w kwestii optymalizacji i zamiast zwracać pełne dane to zaczęli tę naszą listę SC zwracać na zasadzie stream'u. Dzięki temu mogliśmy np. wykorzystać bibliotekę oboe.js to parsowania JSONa w locie.

Oczywiście spróbowałem tego podejścia, no bo w końcu ktoś to wpisał do zadania w Jirze, trzeba było sprawdzić co nie? 😜 Fajnie, JSON parsował się "w locie", ale stream zamiast 10s trwał 30s, a jeszcze nie zacząłem nawet budować drzewa. Dlatego odpuściłem i postanowiłem poszukać gdzie indziej.

Web-worker

Podejście z web-workerem też przetestowałem. Ale tu napotkałem zupełnie inny problem. Ok - mogę sobie pobrać 1M elementów i zbudować na tej podstawie drzewo, ale muszę je później przesłać z wątku web-workera do wątku głównego. Struktura drzewa jest dość obszerna, razem z danymi, które zapisywaliśmy w tej płaskiej strukturze paths. Jeśli chcemy przesłać tak duże dane z jednego wątku do drugiego, przeglądarka musi te dane zserializować, przesłać, a następnie ponownie sparsować. To też powodowało "zamrożenie" przeglądarki na czas przesyłania z jednego miejsca pamięci do drugiego. Oczywiście są sposoby na przesłanie "bezpośrednie" (bez kopiowania) poprzez tzw. Transferable Objects np. ArrayBuffer, ale uznałem, że na chwilę obecną to może być gra nie warta świeczki i postanowiłem sprawdzić, czy faktycznie ta nasza implementacja drzewka była tak zajebista jak myśleliśmy 😜

Profiler podejście pierwsze

Usiadłem przed ekranem komputera, odpaliłem dev-toolsy i wcisnąłem przycisk "record" w Profilerze. Po chwili dostałem taki kolorowy wykresik, który przypomniał mi czasy defregmentatora dysków z Windowsa 98 🤣

Flame graph

Pierwsze co rzuciło mi się w oczy to ten fioletowy kolor, który zanurkował bardzo, bardzo głęboko. Po bliższym spojrzeniu okazało się, że bardzo dużo tych fioletowych elementów to sprawka immer.js. Szybki rzut oka w dokumentację i boom! strzał w dziesiątkę. Okazuje się, że przy "wkładaniu" dużej ilości danych poprzez immer możemy przyspieszyć ten proces poprzez Object.freeze tutaj więcej info. Zabieg ten pozwolił mi na zejście z 12,54s na 11,24s dla 54K elementów. Dla 1M skok był oczywiście proporcjonalnie większy. No ale to nadal nie było to...

Od profilera, do źródeł

Wiedzieliście, że jak klikniecie na dany blok w Profilerze, a następnie przeniesiecie się do pliku, to dostaniecie czasy dla poszczególnych bloków kodu? Nie!? 😎 To teraz już wiecie ;)

Czasy przed optymalizacją dla buildTree

To co się rzuca w oczy to 229ms dla zbudowania prostego ciągu znaków 🤯 jakim jest aktualna ścieżka. Okazało się, że to zwykłe niedopatrzenie można było zastąpić krótszym kawałkiem kodu, który koniec końców zajmuje 1.7ms.

Czasy po optymalizacji dla buildTree

Pomyślicie - (ironicznie) wow... 227ms... "brawo Ty" 👏. Czym jest 227ms? Jeśli spojrzymy na to jako pojedynczą wartość - to fakt...mikro-optymalizacja. Ale pamiętajcie, że celem było obsłużenie 1M elementów, a operacja sklejania ścieżki dotyczyła każdego sub-folderu.

Mój spread operator AKA Object.assign taki piękny

Jak zrobić płytką kopię obiektu, bądź rozszerzyć inny obiekt - nic prostszego - spread operator .... Jeśli musicie wspierać przeglądarki takie jak IE11, to pewnie korzystacie z babel.js - tak jak my...no i taki spread operator, koniec końców jest tłumaczony na Object.assign (w wielkim uproszczeniu).

Object.assign jest stosunkowo wolny i przy większej skali może sprawiać problem. W tym przypadku postawiłem na zwykłe kopiowanie per klucz. Dzięki temu prostemu zabiegowi zbiłem 154ms do 44ms. I znowu, dla pojedynczych elementów to nie ma absolutnie żadnego znaczenia, ale kiedy iterujemy po dużym zbiorze danych takie optymalizacje mogą zdziałać cuda.

Dan Abramov o Object.assign

Agregacja wartości

Po "podkręceniu" immera i wyrzuceniu kliku Object.assign, bądź przepisaniu ich na prostą pętlę, skończyły mi się pomysły na "proste" optymalizacje. Trzeba było podkręcić sam sposób budowania drzewa.

Poprzednia implementacja, dzieliła sobie SC lokacje wg. źródła i dla każdego z nich budowała pod-drzewo. Dla każdego pod-drzewa liczone były zagregowane wartości (np. jeśli folder sam w sobie zawierał 10 SC, ale miał dodatkowo 50 sub-folderów, chcieliśmy pokazać zsumowane wartości). Dla każdego takiego pod-drzewa, wykonywane były sumowania, a następnie węzeł źródła był aktualizowany wg. zsumowanych wartości dla wszystkich folderów.

Każda taka operacja wrzucała coś do stanu w redux'ie. Pomyślałem - a na co to komu? A komu to potrzebne? Przecież nie pokazujemy drzewa dopóki wszystko nie jest policzone i zaktualizowane. Dlatego, zmieniłem kod tak, aby najpierw zbudować w pamięci całe drzewo wraz z policzonymi zagregowanymi wartościami, a następnie za pomocą jednej operacji, wsadzić zbudowane drzewo do reduxa.

Co więcej - w wymaganiach drzewka, było napisane, że pewne węzły miały być domyślnie rozwinięte np. pierwszy poziom + potencjalnie wcześniej zaznaczony element na liście (z listy do drzewka można przejść za pomocą prostego przycisku). Wcześniej operacje rozwijania były wyzwalane za pomocą akcji toggleNode. To też zmieniłem - zamiast odpalać reduxową akcję, po prostu zmieniam wartość expanded na true bezpośrednio w obiekcie węzła.

Można zapytać - co Ci to dało drogi Panie?

Dla 54K elementów zjechałem z czasu 12,25s na 2,4s 🚀

Łogień w szopie :) Product Owner cały w skowronkach.

Testy dla 1M

Poprosiłem backendowców, żeby przygotowali mi środowisko do testów dla 1M elementów. Chciałem sprawdzić czy moje optymalizacje dla 54K znajdą uzasadnienie. No i uśmiech nie uciekł z mej twarzy :)

Przed optymalizacją czas budowania drzewa wynosił ~3,5 minuty. Po zaaplikowaniu wyżej wymienionych zmian udało się zjechać do 59s.

Mniej więcej ~70% oszczędności. W sumie można by powiedzieć - job done - miało się budować w mniej niż 60s... 59 to mniej niż 60 😅 Jest git...

Trochę byłem już zmęczony tym grzebaniem w de-facto w nie swoim kodzie...ale kumpel z zespołu słusznie stwierdził:

No fajnie, fajnie, ale dla mnie nadal to jest wolno.

Dodał też potem, że nic mi nie ujmuje i wg. niego wykonałem kawał dobrej roboty...ale trudno było się z nim nie zgodzić. Od momentu kliknięcia w element nawigacji, do czasu wyświetlenia widoku, użytkownik musiał poczekać łącznie 90s:

25s pobieranie danych (streaming)
6s przeglądarka parsuje JSONa
59s budowanie drzewa

Jako użytkownik, gdybym przez 90s widział tylko spinner ("kręciołek") to by mnie szlag trafił :) Nie chcę myśleć, co czuli nasi użytkownicy jak musieli czekać 3,5 minuty...pewnie żaden nie wytrzymał 😅

...no...ale wracając...kumpel mówi: "wolno"...no to ja od razu: "co!? wolno!? ja Ci pokażę!" 🤣

Generowanie ID

Znowu zanurkowałem w Profiler. Dla meta-folderów generowny był folderId. Było to spowodowane tym, że inne miejsce w kodzie tego id potrzebowało (mniejsza o to). Koniec końców to generowane id nic nie znaczyło (nigdy nie było wysyłane do backendu). Ktoś jednak wymyślił, że to meta-folder-id ma być haszem ze ścieżki...

export const createUniqueIdForLocation = path => btoa(encodeURIComponent(path))

Funkcja btoa koduje ciąg znaków jako base64. Sama w sobie trwa średnio 0,25ms...czyli ułamek milisekund. Ale gdy mocniej się zastanowimy - a na co komu ten hasz? a na co komu to potrzebne?

No właśnie! Jeśli meta-folder-id to tylko base64 ze ścieżki, która de facto zawierała też w sobie id źródła, więc była unikatowa względem całej listy, to po co to w ogóle ten cały hash?

-            id: createUniqueIdForLocation(path),
+            id: path,
             name: getLocationName(path),

Ten jeden diff sprawił, że dla 1M elementów zszedłem z 59s na 35s, co dało ~40% zysku 🤯

Czyli teraz klient nie czekał już 90s a 66s - łącznie z pobieraniem i parsowaniem danych! Biorąc pod uwagę, że wymagania mówiły o budowaniu drzewka w czasie mniejszym niż 60s, to chyba Product Owner oraz klienci powinni być zadowoleni 😅

Dalsze kroki

Oczywiście nie spoczywamy na laurach. Blokowanie użytkownika na 60s nadal jest kiepskim pomysłem, dlatego dalej myślimy o ulepszeniu implementacji. Być może wyrzucimy to w końcu do web-workera. Kto wie? Może uda mi się dzięki temu zebrać materiał na następnego posta 😉.

Podsumowanie

Lekcja pierwsza - zamiast gdybać i sypać pomysłami z kapelusza o web-workerach, lepiej odpalić Profiler.

Lekcja druga - jeśli operujesz w dużej skali, iterujesz po dużym zbiorze danych, to optymalizacje na poziomie ms dla jednej iteracji potrafią czynić cuda 🚀

Lekcja trzecia - do reduxa wrzucaj dopiero wtedy, kiedy jesteś gotów 💪

Lekcja czwarta - jeśli nie ma potrzeby, to nie komplikuj sytuacji 😉 (patrz ID & btoa).

Mam nadzieję, że dzięki tej historii sięgniecie wcześniej do Profilera i uda się Wam poprawić wydajność nie jednej aplikacji.

10 złotych rad dla junior developera

Tue, 22 Sep 2020 00:00:00 GMT

Czy ten tytuł to clickbait? Oczywiście, że tak. Nie ma na świecie dwóch takich samych osób. To co sprawdziło się u mnie niekoniecznie musi się sprawdzić u Ciebie. Tak prawdę mówiąc, to tytuł tego posta powinien brzmieć "Co chciałbym przekazać sobie, gdybym dzisiaj miał zaczynać jako junior developer". Ale uznałem, że to trochę zbyt długie. Kto wie, może niektóre z poniższych wskazówek przydadzą się Tobie. Czy niektóre z tych rad są kontrowesyjne? Pewnie tak. Ale wszystkie z nich są szczere, i właśnie takie chciałbym usłyszeć gdybym wchodził jeszcze raz w świat IT. Traktruj ten wpis, raczej jako taki list Przemka do Przemka :)

TL;RD

nie buduj portfolio
załóż konto na Twitterze
uważaj na celebrytów-IT
nie kupuj książek
eksperymentuj, baw się kodem
naucz się świadomie zarządzać czasem
zainwestuj w umiejętności miękkie
znajdź mentora
kup notatnik
doszlifuj anglielski

Nie buduj portfolio

Kiedy zaczynałem szukać swojej pierwszej pracy jako programista (2012 r.) nie wiedziałem, że wyląduję na frontendzie. Nie miałem konta na githubie. Nie miałem portfolio. I gdybym dzisiaj miał szukać pracy, to też bym takiego portfolio nie budował. A już na pewno nie wrzucałbym tam aplikacji typu ToDo List, albo Weather App. Nie zrozum mnie źle, pisanie takich aplikacji jest jak najbardziej ok. Dzięki temu uczysz się jak składać działającą całość. Ale wrzucanie tego do portfolio jak dla mnie nie ma sensu.

No dobra...ale co zamiast portfolio?

Odpowiedź jest prosta - Open Source. Na githubie jest mnóstwo bibliotek, do których możesz kontrybuować. Wybierz sobie swoją, przeczytaj dokumentację, spróbuj zbudować lokalnie, zobacz jak wygląda lista Issues - z czym ludzie mają problemy. Dzięki temu nauczysz się o wiele więcej niż przy ToDo czy Weather App. Czytanie cudzego kodu to jedna z najważniejszych umiejętności w byciu programistą. Mówiąc o kontrybucji do Open Source, nie mam na myśli np. nowych ficzerów Reacta (chociaż do odważnych świat należy). Czasami jedna linijka kodu potrafi rozwiązać czyjś problem. Ba! Nie musisz wcale kodować. Pisanie dokumentacji to też cegiełka do Open Source. Pierwszy commit Kent C Dodds'a w ramach Open Source to była literówka. Nie wierzysz? - zobacz ten wpis.

Podsumowując - jedno Twoje zdanie podczas rekrutacji - "aktywnie udzielam się w świecie Open Source" znaczy więcej niż portfolio z fajerwerkami.

Załóż konto na Twitterze, ale ...

Znowu - kiedy zaczynałem szukać pierwszej pracy, jedynym portalem typu social media był dla mnie Facebook. Dopiero po czasie zobaczyłem ile mnie omija. Jeśli chcesz być na bieżąco z informacjami dot. technologii to Twitter jest chyba najlepszą opcją. Facebook = rodzina i przyjaciele, sprawy for fun, śmieszki, heheszki, memy, zdjęcia. Twitter = nowinki technologiczne, ciekawi ludzie z branży, motywacja, inspiracje. Dlatego, jeśli jeszcze nie masz konta na Twitterze, to czym prędzej je zakładaj. Poszukaj kilku osób z branży, a potem poszerzaj listę obserwowanych. Nie bój się również usuwać ludzi z listy. To nie są Twoi przyjaciele - nikt się nie obrazi :) Jeśli nie podobają Ci się treści, jakie wrzuca obserwowana przez Ciebie osoba - po prostu przestań ją obserwować, albo wycisz jej tweety.

Z durgiej strony - nie obrażaj się, jak Twój "idol" wrzuci od czasu do czasu posta niekoniecznie związanego z programowaniem. Koniec końców jest to portal typu social media. Zrzut ekranu ze Spotify jeszcze nikomu krzywdy nie zrobił ;)

No ale, co z tym "ale"?

Uważaj na celebrytów-IT

pfff "że co!?". Wierz mi, albo nie, "kiedyś to było". Może inaczej - kiedyś to NIE - było tylu blogów, tylu informacji, tylu kursów, tylu "mentorów". Z czasem ludzie podchwycili temat pt. "praca w IT = dużo hajsu". Zaczął się napływ ludzi do branży, bo to przecież "łatwe pieniądze". Siedzi się tylko i klepie w klawisze. Jak grzyby po deszczu zaczęły wyskakiwać kolejne szkoły programowania, bootcampy, kursy, mentorzy. Zrobił się z tego niezły biznes. Przecież każdy chce zarobić - co nie? - co w tym złego?

Nic. Jeśli masz pieniądze to je wydajesz jak chcesz. Gdybym tylko miał sobie dawać w tej kwesti radę, to powiedziałbym "uważaj na celebrytów w IT". Trochę takich ludzi szufladkuję, sorry. Naczytali się Aniserowicza i Szafrańskiego, jak to można zarabiać na blogu, kursach itp. Sami ledwo co skończyli bootcamp, liznęli pierwszej pracy a już wydają swój autorski kurs - "Programowanie w HTML dla zaawansowanych". Brzmi jak dowcip? Niestety. Brzmi jak zazdrość - kto wie - być może. Niestety nikt nie uczy tego, jak odfiltrować dobry content od tego skopiowanego i nastawionego na szybki zysk. Czasami nie jesteśmy w stanie zweryfikować doświadczenia danej osoby. Kto wie - może naczytał się pierdół o żabach i teraz na siłę próbuje zainteresować tym innych :) Sam musisz sobie wyrobić czujnik na takie osoby - Przemku.

Dobra wiadomość jest taka, że tych dobrych "dusz" jest więcej. A takie celebryto-IT-pijawki zdarzają się sporadycznie.

PS. Nie zrozum mnie źle. Dzielenie się wiedzą na blogu, vlogu (whatever) nawet jeśli dopiero co nauczyłeś się "czegoś" jest SUPER! Ale natychmiastowa próba zarabiania na tym - już nie - przynajmniej nie dla mnie. Gdy płacę za kurs, to chcę mieć pewność, że dana osoba "zęby na tym zjadła", a nie naczytała się pierdół o żabach ;)

Nie kupuj książek

A przynajmniej tych o technologiach. A już na pewno nie kupuj ich z myślą "kiedyś przeczytam". Książki o technologiach szybko się starzeją. Zwłaszcza te o technologiach frontendowych, o frameworkach itp. Jeśli chcesz mieć fajną podstawkę pod monitor - spoko, your choice :) Mam takie dwie cegły pt. JAVA ^^ #naPóźniej.

Zamiast tego, skup się na książkach ponadczasowych. "Clean Code", "Clean Coder", "Pragmatyczny Programista", "Zawód Programista", "Refaktoryzacja" ... to są książki, które się nie starzeją. Po takie książki warto sięgać kilkukrotnie w swojej karierze. Za każdym razem wyciągniesz z niej coś innego, będziesz miał inny punkt widzenia, inny poziom doświadczenia.

I żeby było jasne - nie ma nic złego w książkach o samych technologiach/frameworkach - o ile kupisz aktualną wersję i przeczytasz ją zaraz po zakupie. W innym przypadku - "daj se siana" ;)

PS. Jeśli możesz - czytaj w oryginale, inaczej mówiąc - uważaj na tłumaczenia. Wiem, że oryginały są znacznie droższe w porównaniu z wydanymi nad Wisłą "tłumaczeniami" - ale warto. Obserwuj takie strony jak HumbleBundle, tam często pojawiają się "paczki" książek np. z wydawnictwa O'Reilly Media i można je dostać za "śmieszne" pieniądze.

Eksperymentuj, baw się kodem

Często na grupach dla początkujących czytam: "najpierw skup się na podstawach, dopiero potem zajmij się Reaktem". Ding-dong - Bullshit dector - Ding Dong. Owszem - podstawy pt. zmienne, pętle, funkcje wypadałoby ogarnąć przed frameworkiem. Ale jak już łykniesz podstawowej składni to śmiało wypływaj na głębie. Podczas nauki samego Reakta otrzesz się o funkcje wyższego rzędu, kompozycje, destrukturyzację i to w takiej praktycznej formie. Nie ma sensu czekać!

It's fine to learn React while you're learning JavaScript. Frameworks can teach you closures, higher order functions, ternaries, etc...
— Eric Elliott (@_ericelliott) June 6, 2020

Inny wymiar tej rady mówi o tym, że programowanie powinno sprawiać Ci frajdę. Nie bój się napisać "brudnego kodu", eksperymentuj, baw się. Wykorzystaj różne podejścia. Sprawdź w czym najlepiej się czujesz.

W programowaniu chodzi o rozwiązywanie problemów. A najpiękniejsze w tym wszystkim jest to, że wiele problemów można rozwiązać na wiele, wiele, wiele różnych sposobów.

I na koniec - jeśli masz już za sobą ciężki bój przez te "podstawy", a pisanie każdej kolejnej linijki sprawia Ci ból - to zastanów się czy to na pewno dla Ciebie. Praca programisty nie jest usłana różami, czasami trzeba zanurkować w niemałe szambo i nikt Cię za to po plecach nie poklepie. Z drugiej strony - nie samymi programistami IT stoi. Do branży można wejść na różne sposoby ;)

Naucz się świadomie zarządzać czasem

Z niecierpliwością czekam, aż mój kolega Radomir, zbierze się w sobie i wygłosi prezentację na temat zarządzania czasem. Sprzedał mi ten temat kiedyś przy jakiejś kawie. Główny przekaz jest mniej więcej taki - jeśli jesteś na studiach to nawet nie wiesz ile masz wolnego czasu. Dopiero (o zgrozo) po czasie dochodzi do nas, ile cennych minut przepaliliśmy. I żebyśmy się dobrze zrozumieli - nie ma nic złego w naparzaniu po nocach w Counter Strike'a (gra się jeszcze w to?). Nie ma nic złego w imprezowaniu. Jest taki okres w życiu człowieka - studia - gdzie dopiero poznaje się "co to życie". Korzystaj póki możesz :) Ale pamiętaj - już nigdy nie będziesz miał tyle czasu co teraz. Każdy z nas ma tyle samo czasu. Doba ma 24 godziny. Różnimy się tym, jak ten czas wykorzystujemy. Naucz się swoich nawyków. Swojego organizmu. Sprawdź kiedy jesteś najbardziej produktywny, kiedy najlepiej się uczysz. Wykorzystuj to. Naucz się świadomie zarządzać czasem.

Ostatnio na Twitterze napisałem, że praca programisty to nieustanna nauka. Tak jest. Na tę naukę też trzeba umieć znaleźć czas. Chcesz prowadzić bloga? Sprawdź ile czasu zajmuje napisanie posta. Kanał na Youtube? Kurs gita, czy babela nagrywam już chyba od lutego :) To nie jest proste. Na wszystko trzeba znaleźć ten cholerny czas. Dlatego Przemku - naucz się świadomie zarządzać czasem.

Zainwesuj w umiejętności miękkie

Do pierwszej pracy dostałem się na staż. To nawet nie było stanowisko juniorskie. Kiedyś staż kojarzył mi się z parzeniem kawy i wpinaniu kartek do segregatora (tak tak, i jeszcze za to Unia płaciła...ale ciiiiii 🙊). Ale w Samsungu było inaczej. Konkretny projekt, konkretni ludzie, ogrom wiedzy. Dacie wiarę, że startowałem do zespołu C++ (myślałem, że jak kodowałem w tym języku na studiach to się uda) a dostałem się do zespołu SmartTV, w którym pisaliśmy we frontendowych technologiach? W życiu bym nie powiedział. Dla mnie JS kojarzył się tylko z jQuery i śnieżynkami na stronach. No ale nie o tym chciałem pisać.

Byłem zielony - to fakt. Szybko musiałem nadrobić wiedzę. Udało mi się to dzięki wspaniałym ludziom, z którymi miałem okazję pracować - ale o tym będzie następna rada. Pomimo braku w wielu kwestiach techniczncyh - dosyć szybko awansowałem. Dostałem też możliwość poprowadzenia małego zespołu. Mój szef coś we mnie dostrzegł. Od liceum bardzo lubiłem nawiązywać nowe kontakty. Uważałem się za duszę towarzystwa. Tu coś zagrać na gitarce, tu zagadać, tu się pośmiać. Spotkałem świetnych ludzi na swojej drodze. Byłem szczery, życzliwy, pracowity (teraz też jestem, żeby nie było 😜). Z perspektywy czasu widzę, że to właśnie relacje jakie budowałem z ludźmi pozwoliły mi tak szybko awansować, tak szybko stanąć na czele zespołu.

Bardzo często nie doceniamy umiejętności miękkich w IT (chociaż zauważam zmieniający się trend). Zdradzę Ci teraz pewien sekret - Przemku - pisanie kodu to nie wszystko. Ba! Umiejętna komunikacja i zdolność do budowania relacji znaczą o wiele więcej niż klepanie kodu.

Dlatego - zainwestuj w umiejętności miękkie. Sprawdź jak dobrze się komunikować - bo to wcale nie jest takie łatwe.

Znajdź mentora

W poprzednim punkcie pisałem o świetnych ludziach, z którymi miałem przyjemność współpracować. Szymon K., Grzegorz D., Bartek K., Maciej W. (trochę jak z kryminału :D...no ale nie wiem czy chcieliby się znaleźć tu z nazwiska więc dla pewności zostawiam tak :))...wiele by wymieniać. Wszysktich ich łączy jedno - dążyłem do tego, by być na zbliżonym do nich poziomie. Nie porównywałem się, bo to nie ma sensu. Każdy ma swoją drogę, swoje przeżycia, doświadczenia. Ale możemy się inspirować, czerpać wiedzę, pytać o przeżycia i bazować na doświadzczeniu innych. Dzięki temu zwiększałem prędkość nauki i wchodzenia na wyższy level. Dzisiaj nie wyobrażam sobie pracy w środowisku, w którym nie mogę uczyć się od lepszych od siebie. Zawsze szukam takiej osoby i staram się inspirować.

PS. Pamiętaj, że to może działać w dwie strony. U kogoś widzisz rzecz, której Tobie brakuje...za to ta druga strona widzi w Tobie rzeczy, które ją inspirują do działania. Dzięki temu wzajemnie się napędzacie.

Kup notatnik

Wszyscy mówią - załóż bloga, załóż kanał na YT. A ja mówię - kup notatnik. Taki zwykły zeszycik A5 może być. Zapisuj tam skrzętnie to, czego się nauczyłeś. Czytając książki, bądź oglądając kursy - rób notatki. Spisuj swoje osiągnięcia. Zapisuj przemyślenia. Rysuj mapy myśli. To pomaga - serio. Pomaga - ale z czasem. Np. podczas rozmowy o podwyżkę. Takie rozmowy często odbywają się raz do roku. Czy jesteś w stanie z pamięci wyrecytować wszystkie swoje osiągnięcia. Podpowiem Ci - NIE!. Czasami robimy małą rzecz dla siebie, ale wielką dla projektu. Zapisując swoje wszystkie sukcesy i porażki jesteś w stanie popłynąć na takiej ocenie rocznej i wywalczyć upragnioną podwyżkę. Ale nie rób notatek dla pieniędzy :) rób je dla siebie i dla swojego mózgu, który nie zawsze jest w stanie wszystko spamiętać ;)

PS. Bloga też sobie załóż jak chcesz - dziel się tam swoją nowo-zdobytą wiedzą i doświadczeniem. Tylko proszę - nie nastawiaj się od początku na "zarabianie z bloga". Nie każ mi akceptować powiadomień i zapisywać się do newslettera :) Na początku bloga prowadź go dla siebie. Sława i splendor przyjdą z czasem....albo i nie :P

Doszlifuj angielski

W liceum nie byłem jakoś specjalnie zainteresowany angielskim. Tu trójeczka, tam czwóreczka, tu coś ściągnąć, tam zagadać i "jakoś to będzie". Szybko tego pożałowałem. I choć nie miałem problemu w zrozumieniu słowa pisanego (dokumentacja, książki, maile) to szybko zarobiłem "plaskacza" w momencie, kiedy miałem poprowadzić spotkanie czy prezentację po angielsku. Mówi się, że podstawowym językiem programisty jest język angielski - to prawda. I chociaż coraz więcej publikacji powstaje w języku polskim, tłumaczone są dokumentacje (patrz React) to nadal - posługiwanie się językiem angielskim to podstawa. Bardzo dużo dają tzw. English-Days. W Suncrapers, w którym miałem okazję pracować, był taki jeden dzień - chyba czwartek z tego co pamiętam. W czwartki rozmawiało się tylko po angielsku. To nic, że w projekcie sami polacy. Trzeba było tłumaczyć i szprechać po inglishu. Wiadomo - dla ludzi, którzy dużo się oczytali, ale mało mówili to był problem. Wytłumaczenie prostej rzeczy zajmowało x2, x3 albo x4 tyle co po polsku. Z drugiej strony dzięki takim zabiegom później było łatwiej :)

Dzisiaj nie mam już problemu z posługiwaniem się językiem angielskim. Cały czas pracuję nad wzbogacaniem słownictwa (aktualnie trenuję z dziećmi Ba-Ba-Black Sheep ;))

Dlatego Przemku, jeśli to czytasz i chcesz wejść do IT - to wiedz, że bez angielskiego - ani rusz!

Podsumowanie

I to by było na tyle. Takie rady dałbym sobie dzisiaj, gdybym miał zaczynać jeszcze raz w IT. Banalne? Kontrowesyjne? Nudne? Dajcie znać w komentarzach ;)

Uwaga na fixtury w cypress.io

Fri, 26 Jun 2020 00:00:00 GMT

Dzisiaj opowiem wam krótką historię o błędzie, który kosztował mnie dwa dni poszukiwań. Błędzie, który koniec końców okazał się czymś bardzo trywialnym, a czas który spędziłem na debugowaniu spowodowany był niedokładnym komunikatem o błędzie.

Hej Przemek! Czy mógłbyś mi pomóc?

Kilka dni temu, zauważyłem, że nasze testy VRT (Visual Regression Tests) zaczęły się sypać dla jednego przypadku. Poprosiłem moją koleżankę z zespołu, Monikę, aby rzuciła na to okiem. Monika przyjęła wyzwanie i bezzwłocznie zaczęła szukać rozwiązania. Po całym dniu bezowocnych poszukiwań powiedziała, że nie ma pojęcia dlaczego to nie działa. Lokalnie test przechodził za każdym razem, niestety na naszym GitlabCI było zupełnie odwrotnie. Dziwna sprawa co nie? Jak to jest, że "u mnie działa" a na CI już nie? Zrezygnowana Monika poprosiła mnie o pomoc. Po dwóch dniach kombinowania, commitowania, wypychania, czekania i sprawdzania w końcu się udało.

Fake server

W naszej aplikacji do testów wykorzystujemy różne narzędzia. Do unit testów mamy jest. Do testów E2E mamy py.testa z bindigami do webdrivera. Mamy też testy UI, które sprawdzają naszą aplikację pod kątem integracji pomiędzy komponentami, stronami czy widokami. Niedawno wprowadziliśmy także VRT - wizualne testy regresyjne. Te dwa ostatnie rodzaje testów wykorzystują cypress.io. Jest to świetne narzędzie do pisania wszelakich testów - od unitów do E2E.

Nasza aplikacja od strony backendowej jest bardzo skomplikowana i ciężko ją postawić w całości na lokalnym komputerze, a nawet jeśli jest to możliwe - kosztuje to wiele pracy i zasobów komputera. Dlatego do testów UI i VRT wykorzystujemy jeden z killer-featureów Cypressa, który pozwala mockować zapytania do API. Cypress wpina się pomiędzy aplikację i żądanie do serwera, a my możemy zdecydować o tym jaką odpowiedź dostanie nasza aplikacja.

it("test with network stubbing", () => {
  // Po pierwsze musimy powiedzieć, że stawiamy fake-server
  cy.server()
  // Dalej deklarujemy jakie ścieżki chcemy mockować
  cy.route("/api/endpoint", { value: 1 })
})

Więcej o tym przeczytacie w oficjalnej dokumentacji Cypressa.

Fixtury

Fixtury to kolejna z funkcjonalności cypress.io, z której korzystamy - szczególnie w testach VRT. Fixtura to nic innego jak pewne dane zapisane w pliku, które możemy wykorzystywać wiele razy. Pomaga to w organizacji testów i zarządzaniu odpowiedziami z naszego cy.route. Żeby załadować fixturę korzystamy z komendy cy.fixture. Jako argument przyjmuje ona relatywną ścieżkę do pliku, znajdującego się w katalogu z naszymi fixturami. Domyślnie katalog na fixtury nazywa się po prostu fixtures, a same pliki z fixturami mogą mieć różne rozszerzenia. Nie muszą też być używane w kontekście cy.route. Więcej o fixturach znajdziecie w oficjalnej dokumentacji cypressa.

Załóżmy, że mamy następującą strukturę plików:

- fixtures
    - myFixture.json
    - someSubFolder
          - mySecondFixture.json

Kod, który wykorzystuje fixtury:

it("test with fixtures", () => {
  // Nie musimy deklarować rozszerzenia pliku
  // Cypress spróbuje sam je odgadnąć
  cy.fixture("myFixture").then(data => {
    // Tutaj możemy odczytać dane
  })

  // Możemy zapisać dane w postaci aliasu ...
  cy.fixture("someSubFolder/mySecondFixture").as("myAlias")

  // Żeby móc go wykorzystać przy mockowaniu network requesta
  cy.route("/api/endpoint", "@myAlias")
})

Twórcy cypressa zadbali też o to, żebyśmy nie musieli pisać tak dużo boilerplateu 🔥🔥🔥. Do komendy cy.route jako parametr reprezentujący odpowiedź z serwera możemy podać skrót do fixtury fixture albo fx

cy.route("/api/path", "fixture:myFixture")
cy.route("/api/endpoint", "fx:someSubFolder/mySecondFixture")

W ten sposób zamockowaliśmy sobie odpowiedzi z serwera, a dane trzymane są w re-używalnych plikach z fixturami. Rewelacja!

Gdzie się podział główny bohater opowieści?

No dobra, ale gdzie ten błąd, z którym walczyliśmy dwa dni?

Na potrzeby reprodukcji utworzyłem bardzo prostą aplikację. Na początku wyświetla ona napis Loading…, wykonuje zapytanie do serwera, a następnie podmienia tekst na to, co zwrócił backend.

Pobieranie danych w starym, dobrym stylu XHR 😎

<body>
  <div id="main">Loading...</div>
  <script>
    const mainEl = document.querySelector("#main")

    const req = new XMLHttpRequest()
    req.open("GET", "/api/endpoint", true)
    req.onreadystatechange = function() {
      if (req.readyState == 4) {
        const msg = req.status == 200 ? req.responseText : "Error"
        mainEl.innerHTML = msg
      }
    }
    req.send(null)
  </script>
</body>

Do tego napisałem test:

describe("Simple fixture test", () => {
  it("displays response", function() {
    cy.server()
    cy.route("/api/endpoint", "fixture:examplefixture")

    cy.visit("/")

    cy.get("#main").should("have.text", "Hello")
  })
})

Oraz utworzyłem plik z fixturą w pliku fixtures/exampleFixture.json z taką zawartością:

Hello

Czy widzisz już gdzie leży błąd?

W odnalezieniu przyczyny problemu pomógł mi zrzut ekranu, który cypress wykonuje w momencie kiedy test nie przejdzie. Kolejny killer feature 🔥.

Zrzut ekranu dla testu

Czy teraz domyślasz się gdzie był błąd?

Moją uwagę przykuł komunikat o tym, że route został co prawda zestubowany, ale odpowiedział kodem 400, a nie 200, co spowodowało błąd w kolejnej komendzie oczekującej na element z tekstem "FolderA". Przypominam, że "lokalnie" ten test nie miał z tym problemu 😉.

Literówka i systemy plików

Nasz błąd, który próbowaliśmy rozwiązać z Moniką, polegał na banalnej literówce. Nazwa pliku z fixturą zapisana była camelCase, natomiast w kodzie testu mieliśmy wszystko małymi literami.

exampleFixture.json vs cy.route("/api", "fixture:examplefixture")

No ok, ale dlaczego to działało lokalnie, a nie działało na CI?

99% naszego zespołu frontendowego pracuje na MacBookach podczas gdy GitlabCi odpala testy w kontenerze dockerowym, który opiera się na Linuxie. Co to ma wspólnego z fixturami i naszą literówką? Otóż system plików używany domyślnie w Linuxie jest caseSensitive (zwraca uwagę na wielkość liter w nazwach plików). MacOS oraz Windows domyślnie opierają się o system plików, który caseSensitive nie jest. Co to oznacza w praktyce?

Na Linuxie możemy utworzyć pliki o tej samej nazwie, ale pisane nieco inaczej np.

myAwesomeFile.js
myawesomefile.js

Linux potraktuje je jako dwa osobne pliki. Natomiast Windows i MacOS nie pozwolą na stworzenie drugiego pliku o tej samej nazwie (pisanej np. camelCase). Przy próbie odczytu pliku np. w node.js na MacOS nie ma znaczenia czy wpiszemy myFixture czy mYFiXtURe - plik zostanie załadowany. Na Linuxie natomiast dostaniemy błąd odczytu - plik nie został odnaleziony.

Sprawdzam

I faktycznie tak jest. Gdy zmodyfikujemy kod naszego testu w ten sposób:

cy.route("/api/endpoint", "fixture:ExAmPlEFiXTuRe")

Test na Macu przechodzi zawsze. Na Linuxie natomiast, cypress logger pokaże nam stuba z kodem 400:

Zrzut ekranu z kodem 400

a w konsoli dostaniemy błąd:

CypressError: The following error originated from your application code, not from Cypress.

When Cypress detects uncaught errors originating from your application it will automatically fail the current test.

This behavior is configurable, and you can choose to turn this off by listening to the `uncaught:exception` event.

https://on.cypress.io/uncaught-exception-from-application

Ale jak to “błąd nie jest w cypressie tylko w mojej apce”? Przecież apka działa, test na Macu też przechodzi - więc o co kaman?

Spróbujmy skorzystać z naszej fixtury za pomocą cy.fixture zamiast skrótu:

// Celowy błąd w nazwie fixtury
cy.fixture("examplEFixture").as("response")
cy.route("/api/endpoint", "fixture:examplefixture")

// Bonusem takiego podejścia jest możliwość użycia aliasu do odczytu danych
// zamiast hardcodować "Hello" w teście
cy.get("@response").then(data => {
  cy.get("#main").should("have.text", data)
})

Jaki teraz dostaniemy błąd?

Error: A fixture file could not be found at any of the following paths:

> cypress/fixtures/examplEFixture
> cypress/fixtures/examplEFixture{{extension}}

Cypress looked for these file extensions at the provided path:
.json, .js, .coffee, .html, .txt, .csv, .png, .jpg, .jpeg, .gif, .tif, .tiff, .zip

Provide a path to an existing fixture file.

👏 no i taki komunikat błędu jest o wiele lepszy. Od razu wiemy gdzie należy szukać 😎

Podsumowanie

Z tej historii można wyciągnąć dwa wnioski:

mała literówka może przysporzyć Ci kilka dni debugowania
jesteś tak dobry jak komunikaty o błędzie z twojego test runnera 😉

Myślę, że cypress mógłby zwracać “poprawny” komunikat o błędnej fixturze zamiast CypressError- dlatego zgłosiłem issue, którego status możecie śledzić tutaj.

Dzięki, że wytrwaliście ze mną w tej historii do końca. Lecę spróbować naprawić issue, które sam zgłosiłem 😉. Może uda mi się dołożyć kolejną cegiełkę do OpenSource i sprawdzić by Cypress, który jest niesamowitym narzędziem, stał się jeszcze lepszy 😁

Zatrzymaj czas z cy.clock

Wed, 22 Apr 2020 17:00:00 GMT

Dziś pokażę Wam jak za pomocą jednej komendy zatrzymać czas. Niestety, tylko w testach napisanych w cypress.io. Jeśli znasz skuteczną metodę na zatrzymanie czasu tak ogólnie - w życiu, to napisz do mnie. Ostatnio krucho u mnie z tym czasem, dlatego każda wskazówka jest na wagę złota. Dobra 🙂 koniec z tym śmieszkowaniem, bierzmy się do roboty.

Opis testowanej aplikacji

Na początek trzeba mieć co testować. Nasza aplikacja będzie do bólu prosta. Wyświetlamy czas wejścia na stronę oraz licznik, pokazujący ile czasu na niej spędziliśmy.

Enter time:

Time on page: 0

import React from "react"

export default () => {
  const [enterDate, setEnterDate] = React.useState()
  const [counter, setCounter] = React.useState(0)

  React.useEffect(() => {
    setEnterDate(Date.now())

    const intervalId = setInterval(() => {
      setCounter(prev => prev + 1)
    }, 1000)

    return () => clearInterval(intervalId)
  }, [])

  return (
    <div>
      <p>
        Enter time: <span data-testid="enter-time">{enterDate}</span>
      </p>
      <p>
        Time on page: <span data-testid="counter">{counter}</span>
      </p>
    </div>
  )
}

Możemy przejść teraz do napisania testu.

Testujemy!

Dla naszej aplikacji chcemy napisać prosty test case sprawdzający:

czy poprawnie wyświetlamy czas wejścia,
czy licznik zwiększa swoją wartość co sekundę.

Spróbujmy w ten sposób:

cy.visit("/")
  .get("[data-testid=enter-time]")
  .should("have.text", Date.now().toString())

Na pierwszy rzut oka kod testu wygląda w miarę ok. Niestety nie przechodzi on weryfikacji 😢

Błąd przy pierwszej iteracji testu

Gdybyśmy zamiast liczby sprawdzali sformatowaną datę np. 22-04-2020 pewnie nie byłoby problemu. No ale nasz klient zażyczył sobie formę milisekund - #jakŻyć? W takim wypadku sprawa się nieco komplikuje.

Z pomocą przychodzi nam komenda cy.clock. Nadpisuje ona globalne funkcje zwiazane z czasem i pozwala na kontrolowanie ich poprzez np. cy.tick().

Funkcjonalności na które wpływa cy.clock to:

setTimeout
clearTimeout
setInterval
clearInterval
Date

Więcej informacji znajdziecie w oficjalnej dokumentacji cypress.io.

Spróbujmy teraz dodać cy.clock do naszego testu:

cy.clock()
  .visit("/")
  .get("[data-testid=enter-time]")
  .should("have.text", Date.now().toString())

Nadal dostajemy błąd, ale kiedy wczytamy się w jego treść zauważymy różnicę:

expected <span> to have text '1587547901669', but the text was '0'

O co chodzi z tym zerem? Ponieważ czas reprezentowany jako timestamp to liczba sekund od rozpoczęcia epoki Unixa (unix epoch), dlatego wartość 0 reprezentuje 1 stycznia 1970. Można by zapytać co stanie się w momencie przekręcenia licznika, czyli 19 Stycznia 2038 roku - ale to już rozkmina na inny wpis 🙂.

Wywołanie komendy cy.clock() bez argumentów ustawia czas dla naszej aplikacji na 1 Stycznia 1970. Dlatego po prawej stronie asercji otrzymaliśmy 0. Żeby to zmienić możemy podać porządaną wartość daty jaką chcemy ustawić:

const now = Date.now()
cy.clock(now)

Dzięki temu być może magicznym trafem uda nam się zgrać z datą ustawioną w linijce odpowiadającej za asercję should("have.text", Date.now().toString());. To zależy jaki szybki mamy komputer 😄. Żeby poprawnie napisać test należy pamiętać o tym, że cy.clock nadpisuje czas w naszej aplikacji a nie w testach. Dlatego wywołanie Date.now() w momencie asercji powinniśmy zamienić na wartość zapisaną wcześniej w clock.

const now = Date.now()
cy.clock(now)
  .visit("/")
  .get("[data-testid=enter-time]")
  .should("have.text", now.toString())

Test przechodzi - zawsze! - sukces!. Jest tylko jedna różnica w działaniu aplikacji. Przed wykorzystaniem cy.clock nasz licznik w testach zmieniał się co sekundę. Po wykorzystaniu cy.clock licznik zatrzymał się na 0. Akurat dla nas jest to porządany efekt. Nie tylko ustawiliśmy porządaną datę ale też zatrzymaliśmy czas.

Aby ruszyć czas o porządaną wartość wykorzystamy komendę cy.tick. Jako argument przyjmuje ona ilość milisekund, o które chcemy przesunąć nasz czas.

const now = Date.now()
cy.clock(now)
  .visit("/")
  .get("[data-testid=enter-time]")
  .should("have.text", now.toString())
  .get("[data-testid=counter]")
  .should("have.text", "0")
  .tick(1000)
  .get("[data-testid=counter]")
  .should("have.text", "1")

Sukces 🎉! Mamy test sprawdzający czas wejścia oraz działanie licznika.

A co jeśli chcielibyśmy ustawić tylko datę? 🤔

Bardzo dobre pytanie. Czasami może jednak zdarzyć się tak, że chcemy wpłynąć tylko na obiekt Date pozostawiając w spokoju setTimeout i inne funkcje związane z czasem. W takim wypadku należy do wywołania cy.clock dodać drugi argument - tablicę funkcji czasu, które chcemy nadpisać

cy.clock(Date.UTC(2020, 3, 22), ["Date"])

W tym przypadku ustawiamy datę/godzinę na 22 kwietnia 2020 00:00 UTC (miesiące w Date liczymy od 0, dlatego 3 to Kwiecień 🙂). Przy takim wywołaniu nie wpływamy na pozostałe funkcje czasu takie jak setTimeout itp.

To tyle na dziś. Uzbrojeni w tę wiedzę możecie teraz zatrzymać czas w swoich testach 😉

Powodzenia!

3 kroki do niesamowitych raportów w cypress.io

Wed, 18 Dec 2019 00:00:00 GMT

W tym wpisie nauczymy się jak wygenerować rozbudowane raporty z testów napisanych w cypress.io. Wzbogacimy je także o zrzuty ekranu, co powinno pomóc w znacznie szybszej naprawie potencjalnych bugów 😄 Wszystko czego potrzebujemy to trzy proste kroki.

Egnyte + testy = ❤️

Utrzymanie możliwie jak najwyższej jakości produktu to jedno z naszych priorytetów w Egnyte. Dlatego kochamy testować 😍. Nasze aplikacje do małych nie należą, dlatego ich ręczne testowanie było by dla nas bardzo wyczerpujące. W związku z tym, automatyzacja testów i technika Continous Integration są naszymi najlepszymi przyjaciółmi. Piszemy wiele rodzajów testów: unit, integration, end-to-end, modułowe itd. Ale to nie nazwy są tu najważniejsze. To co się liczy najbardziej, to pewność, że gdy widzisz zielony pipeline na Jenkinsie, to potencjalnie nie popsułeś żadnej części systemu.

Więc w czym problem? Wiedzieliście, że testy nie zawsze przechodzą? 😱 I to jest jak najbardziej ok :) (przynajmniej do czasu znalezienia przyczyny). Nie musimy od razu panikować. Po pierwsze, spokój. Tylko spokój może nas uratować. Widzimy czerwony pipeline - wchodzimy na Jenkinsa, sprawdzamy co jest nie tak i fixujemy. To tyle. Problem polega na tym, że raport z testów na Jenkinsie to bardzo często, zwykły tekst wraz ze zrzutem ze stack-trace. Taki raport jest jak najbardziej ok dla unit testów albo testów integracyjnych dla naszych komponentów Reactowych, połączeń z Reduxem, itd. Z drugiej strony, taka ściana tekstu nie zawsze jest przydatna dla testów uruchamianych w przeglądarce (full UI). Spójrzmy na fragment raportu dla przykładowego testu:

Raport z testów na Jenkinsie

Tak wygląda podstawowy raport z testu na Jenkinsie dla jednego z naszych produktów (Egnyte Protect). Do pisania testów integracyjnych-UI, korzystamy z bombowego 💣 narzędzia cypress.io. Muszę przyznać, że Cypress wraz z rozszerzeniem cypress-testing-library robią wspaniałą robotę jeśli chodzi o tzw. error messages. Na pierwszy rzut oka widać, że cypress nie potrafił znaleźć elementu z zadaną wartością tekstową. Timed out retrying: Expect to find element: findByText("..."), but never found it. Ok, ale jaki był stan wizualny naszej aplikacji? Jako developer biorący udział w projekcie Egnyte Protect, wiem, że element którego szukamy powinien znajdować się w dialogu. Ale czy dialog został otwarty? A może to tylko literówka? Tyle pytań a tak mało odpowiedzi. Jeśli teraz chcielibyśmy sprawdzić o co biega, musielibyśmy uruchomić testy lokalnie i zobaczyć stan wizualny naszej aplikacji. Dopiero wtedy dowiedzielibyśmy się, że mamy doczynienia (spoiler alert) z literówką :)

A co by było, gdyby zamiast ściany tekstu, pokazać zrzut ekranu z aplikacji?

Zrzut ekranu z testowanej aplikacji

Wow! Teraz wiemy, że dialog został otwarty, i że tekst w nagłówku jest niepoprawny! Dostaliśmy nieoceniony kontekst, potrzebny do zdiagnozowania błędu, od razu w raporcie wzbogaconym o zrzut ekranu.

Zatem, jak to osiągnąć? Jak dodać zrzuty ekranu do raportu z testów? I w końcu - jak taki raport wygenerować? Jedziemy z koksem!

Raport HTML pędzi z pomocą!

Cypress bazuje na frameworku mocha.js. To dla nas świetna wiadomość - ponieważ mocha.js to bardzo dojrzały projekt, posiadający mnóstwo rozszerzeń. Rezultaty testów generowane są w mocha.js za pomocą tzw. reporterów. Taki reporter możemy napisać samemu, albo możemy skorzystać już z istniejącego np. mochawesome. Jak sama nazwa wskazuje, generuje on AWESOME raporty! Badum tsss.

Zobaczmy teraz, jak możemy zintegrować mochawesome z cypress w celu wygenerowania raportu HTML wraz ze zrzutem ekranu dla testów zakończonych błędem. Aby zwizualizować wszystkie zmiany, które wprowadziłem na potrzeby tego wpisu, skorzystałem z przykładowego repozytorium cypress-example-kitchensink. Integrację przeprowadzimy w trzech prostych krokach. Do dzieła!

Krok 1 - setup reportera

Po pierwsze, musimy zainstalować odpowiednie reportery. Tak! Dokładnie - liczba mnoga - reportery. Oprócz generowania raportów HTML, nadal chcielibyśmy wyświetlać wyniki w konsoli, a być może także w specjalnym formacie JUnit XML. Dla każdego, z tego typu wyników, musimy mieć osobny reporter. W tym celu skorzystamy z paczki cypress-multi-reporters, która umożliwia skorzystanie z wielu reporterów dla cypress.io. Oprócz tego musimy zainstalować jeszcze pakiet mocha, oraz oczywiście mochawesome.

npm install --save-dev mocha cypress-multi-reporters mochawesome

Lub jeśli korzystacie z yarn:

yarn add -D mocha cypress-multi-reporters mochawesome

Następnie w pliku konfiguracyjnym cypress.config, musimy wskazać reporter, z którego będziemy korzystać:

{
  "reporter": "cypress-multi-reporters",
    "reporterOptions": {
      "configFile": "reporter-config.json"
    }
}

Pole configFile wskazuje na plik konfiguracyjny reporter-config.json, który zawiera opcje dla poszczególnych reporterów. Plik ten powinniśmy dodać do repozytorium. Zobaczmy teraz jak wygląda jego zawartość:

{
    "reporterEnabled": "mochawesome",
    "mochawesomeReporterOptions": {
        "reportDir": "cypress/results/json",
        "overwrite": false,
        "html": false,
        "json": true
    }
}

Ustawiamy folder docelowy, do którego trafią nasze wyniki. Chcemy, aby zostały one zapisane w formacie JSON, osobno dla każdego pliku z testami. Dlatego ustawiamy flagę html na wartość false. Cypress potrafi uruchamiać testy równolegle, dlatego aby nie nadpisać wygenerowanych już wyników, ustawiamy flagę overwrite na false.

Spróbujemy teraz uruchomić nasze testy za pomocą komendy npm run local:run.

Running:  examples/location.spec.js                                                      (9 of 19)
Location
    ✓ cy.hash() - get the current URL hash (169ms)
    ✓ cy.location() - get window.location (101ms)
    ✓ cy.url() - get the current URL (78ms)
3 passing (1s)
[mochawesome] Report JSON saved to /Users/przemuh/dev/cypress-example-kitchensink/cypress/results/json/mochawesome_008.json

Jak widzicie, w konsoli dostaliśy wyniki dla poszczególnych testów (domyślny spec-reporter). Zaraz pod nimi widzimy informację na temat utworzonego pliku mochawesome_008.json. Każdy plik z testami wygeneruje nam osobny plik z wynikami.

Lista wygenerowanych plików z wynikami testów

Jesteśmy gotowi do implementacji następnego kroku.

Krok 2 - generowanie raportu

Zebraliśmy pliki z wynikami testów. Teraz, musimy połączyć je w jeden plik i na jego podstawie wygenerować raport HTML. W tym celu skorzysamy z narzędzia mochawesome-merge. Zainstalujmy je!

npm i --save-dev mochawesome-merge
yarn add -D mochawesome-merge

Teraz, dodajmy skrypt npm, który będzie odpowiedzialny za uruchamianie narzędzia do łączenia wyników.

"report:merge": "mochawesome-merge --reportDir cypress/results/json > cypress/results/mochawesome-bundle.json"

Flaga reportDir mówi o tym, w jakim folderze znajdują się pliki do połączenia. Wynik łączenia wyrzucony będzie na standardowe wyjście (w naszym przypadku będzie to konsola) dlatego, przekierowujemy wyjście do pliku mochawesome-bundle.json. Jedna uwaga: wynik łączenia powinien znajdować się w innym folderze niż pliki z poszczególnymi wynikami testów. W przeciwnym wypadku dostaniemy błąd.

Po zmergowaniu wyników jesteśmy gotowi do wygenerowania raportu HTML. Potrzebujemy do tego jeszcze jednej paczki mochawesome-report-generator.

npm i --save-dev mochawesome-report-generator
yarn add -D  mochawesome-report-generator

Tak jak w przypadku łączenia, utworzymy sobie teraz skrypt, który będzie uruchamiał narzędzie do generowania raportu HTML:

"report:generate": "marge cypress/results/mochawesome-bundle.json -o cypress/reports/html"

Słówko marge to skrót od MochawesomeReportGEnerator - to tak w ramach gdybyście się zastanawiali :)

Po poprawym wykonaniu skryptu, nasz raport HTML powinien pojawić się w katalogu cypress/results/html.

Widok raportu HTML

Została tylko jedna, mała rzecz. Dodanie zrzutu ekranu do wyniku testu zakończonego błędem.

Krok 3 - zrzut ekranu

Cypress automatycznie generuje zrzuty ekranu dla testów, które z jakiegoś powodu nie przeszły. Jest to domyślne zachowanie, które można wyłączyć. Wygenerowane obrazki zbierane są w folderach, które przyjmują następujacą strukturę:

path-to-the-specfile/spec.file.js/context - describe - describe - testTitle (failed).png

Rozważmy sobie test, który znajduje się w katalogu examples/actions.spec.js:

context('Actions', () => {
  context("nested context", () => {
      it('.type() - type into a DOM element', () => {})
   })
})

Wygeneruje on zrzut ekranu, który znajdzie się w następującej strukturze folderów:

Struktura folderów ze zrzutem ekranu

Ok, to jak połączyć te dwa elementy: zrzut ekranu wygenerowany przez Cypress i wynik testu wygenerowany przez mochawesome reporter?

Po pierwsze, skopiujmy sobie nasze zrzuty ekranu do folderu, w którym trzymamy nasz raport HTML. W tym celu napiszemy sobie kolejny skrypt npm:

"report:copyScreenshots": "cp -r cypress/screenshots cypress/results/html/screenshots"

Następnie, w pliku cypress/support/index.js, napiszmy kawałek kodu odpowiedzialny za nasłuchiwanie na event test:after:run

Cypress.on("test:after:run", (test, runnable) => {
    if (test.state === "failed") {
        // do something
    }
});

Aby dodać zrzut ekranu do wyniku testu, musimy skorzystać z metody addContext z pakietu mochawesome. Metoda ta, przyjmuje dwa argumenty: obiekt z testem oraz tzw. context. Jeśli context jest poprawnym adresem URL (może być lokalną ścieżką) do obrazka, wtedy obrazek ten będzie wyświetlany pod wynikiem testu. Oczywiście to nie musi być tylko obrazek. Po więcej info odsyłam do dokumentacji.

import addContext from 'mochawesome/addContext'

Cypress.on("test:after:run", (test, runnable) => {
    if (test.state === "failed") {
        const imageUrl = "?";
        addContext({ test }, imageUrl);
    }
});

Wszystko spoko, ale skąd mamy wziąć ten imageUrl ? ...

Pora na odrobinę magii

Żartuję :) Skorzystamy z API jakie daje nam mocha, a dokładniej z tzw. runnable object. Jak widzieliśmy wcześniej, Cypress generuje nazwy obrazków na podstawie struktury testu. Musimy to teraz odtworzyć:

Cypress.on('test:after:run', (test, runnable) => {
  if (test.state === 'failed') {
    let item = runnable
    const nameParts = [runnable.title]

    // Iterate through all parents and grab the titles
    while (item.parent) {
      nameParts.unshift(item.parent.title)
      item = item.parent
    }

    const fullTestName = nameParts
            .filter(Boolean)
            .join(' -- ')           // this is how cypress joins the test title fragments

    const imageUrl = `screenshots/${
      Cypress.spec.name
    }/${fullTestName} (failed).png`

    addContext({ test }, imageUrl)
  }
})

Od tej chwili, jeśli nasz test zawiedzie, w naszym pliku wynikowym zostanie doklejony context z adresem do wygenerowanego obrazka:

{
  "title": ".type() - type into a DOM element",
  "fullTitle": "Actions .type() - type into a DOM element",
  "timedOut": null,
  "duration": 10395,
  "state": "failed",
  "speed": null,
  "pass": false,
  "fail": true,
  "pending": false,
  "context": "screenshots/examples/actions.spec.js/Actions -- .type() - type into a DOM element (failed).png",
}

Co więcej - obrazek ten zostanie dodany do raportu HTML.

Raport HTML wraz ze zrzutem ekranu

TADA 🎉 Mamy to!

Wszystkie zmiany, których dokonaliśmy, możecie zobaczyć w jednym miejscu: https://github.com/przemuh/cypress-example-kitchensink/pull/1/files

Kroki opcjonalne

Dobrym pomysłem jest dodanie do .gitignore folderów cypress/results i cypress/reports.

Fajnie było by też "czyścić" foldery z generowanymi assetami (wyniki, zrzuty, itp.). Jak to zrobić? Zgodnie z "tradycją" dodamy teraz skrypt npm odpowiedzialny za tę akcję:

"precy:run": "rm -rf cypress/screenshots cypress/results cypress/reports"

Te trzy literki "pre", zanczą ni mniej ni więcej, jak to, że skrypt ten odpalony będzie przed wywołaniem skrypu cy:run. Więcej info w dokumentacji npma.

W użytym, przykładowym repo, zainstalowany został pakiet npm-run-all. Możemy z niego skorzystać aby uruchomić wszystkie, stworzone do tej pory skrypty w zadanej kolejności (sekwencyjnie):

"report": "run-s report:*",
"report:merge": "mochawesome-merge --reportDir cypress/results/json > cypress/results/mochawesome-bundle.json",
"report:generate": "marge cypress/results/mochawesome-bundle.json -o cypress/reports/html",
"report:copyScreenshots": "cp -r cypress/screenshots cypress/reports/html/screenshots"

Pozostała jeszcze jedna sprawa do rozważenia. W większości systemów operacyjnych, nazwa pliku ograniczona jest do 255 znaków. Co się stanie jeśli zagnieździmy nasz test wielopoziomo? To proste! Zostanie przycięty :) Cypress sam przycina nazwy wygenerowanych obrazków do 220 znaków. Powinniśmy to odzwierciedlić w naszym kodzie:

const MAX_SPEC_NAME_LENGTH = 220;
const fullTestName = nameParts
    .filter(Boolean)
    .join(" -- ")
    .slice(0, MAX_SPEC_NAME_LENGTH);

Niestety jest to tzw. szczegół implementacyjny. Nie wiemy czy programiści cypressa zmienią kiedyś ten numer. Dlatego, lepszą opcją będzie nie zagnieżdżanie testów na tak głębokich poziomach. Polecam lekturę posta od Kent C Doddsa - Avoiding nesting when you are testing, w którym pokazuje, do jakich problemów może prowadzić zagnieżdżanie w testach.

Podsumowanie

Mam nadzieję, że ten artykuł pomógł Wam w poprawnym skonfigurowaniu środowiska pod generowanie raportów HTML z cypressa. Tego typu raporty bardzo pomagają nam, w Egnyte, w szybkim sprawdzeniu gdzie leży źródło problemu - wierzę, że pomogą i Wam :)

Podsumujmy nasze 3 proste kroki:

Instalacja i konfiguracja reporterów
Zebranie wyników i wygenerowanie raportu HTML
Dekoracja raportu kontekstem - zrzutem ekranu - za pomocą metody addContext.

Wszystkie niezbędne zmiany, możecie zobaczyć w przystępnej formie pull requesta: https://github.com/przemuh/cypress-example-kitchensink/pull/1/files. Oczywiście po wygenerowaniu raportu musicie jeszcze go podpiąć pod narzędzie CI. Ale to już historia na osobnego posta. :)

To jak? Jesteście gotowi na stworzenie swojego raportu HTML z cypress.io?