Po co nam te testy?

Shift-left approach to pojęcie istniejące w świecie testerskim od ponad dwudziestu lat. Zakłada ono weryfikację funkcjonalności już na początkowym etapie developmnetu oprogramowania. W ten sposób można stosunkowo wcześnie wykryć różnorodne nieścisłości. Mam tutaj na myśli błędy popełnione przez developerów, ale także braki w dizajnie czy niepełną analizę pomijającą tzw. scenariusze brzegowe.

Weryfikacja ta polega przede wszystkim na automatyzacji testów które sprawdzają, ,jak działa wdrażane rozwiązanie i czy nie wpłynie ono na uszkodzenie innych komponentów w ekosystemie. Pozwala to na tworzenie w zespołach kultury dobrej jakości i pełności oprogramowania. Developerzy stają się świadomi większej ilości wyzwań związanych z utrzymaniem funkcjonalności w ryzach zaplanowanego scenariusza, co finalizuje się lepszą jakością prac końcowych przekazywanych biznesowi do końcowej akceptacji.

Do właściwego wdrożenia shift-left w codzienny development niezbędna jest dobrze zaprojektowana warstwa dev-ops. Mam tutaj na myśli stworzenie ciągu zadań sprawdzających jakość kodu i oprogramowania, użytych narzędzi oraz wszystkich innych formalności związanych z etapem developmentu. Gdy wszystko to jest spełnione, nowe rozwiązanie może być w sposób automatyczny dostarczone klientom, w zasadzie nawet bez konieczności manualnej weryfikacji po stronie testera.

Zagadnienia te wybiegają jednak daleko poza tematykę tego artykułu. Chciałbym w nim bowiem przybliżyć, w jaki sposób podchodzimy do testowania aplikacji frontendowych w naszym codziennym developmencie.

Weryfikacja jakości kodu

Od kilku lat lubię obserwować, jak młodsi stażem koledzy zaczynają zdawać sobie sprawę, że jakość pisanych przez nich funkcjonalności także jest wynikiem pewnego rodzaju testowania. Mam tutaj na myśli statyczną analizę i automatyczną poprawę kodu źródłowego, realizowaną przez narzędzia pokroju Prettier, Eslint czy Typescript. Są one bowiem nieformalną, najniższą warstwą testów dbających o ogólną czytelność kodu, sprawdzających czy w wywoływanych komendach nie popełniamy literówek i czy nie wybiegamy poza ustalone ramy biznesowe zamknięte w typach danych, na których operujemy. 

Testowanie funkcjonalności na niskim poziomie

Prawdziwe i świadome testowanie zaczyna się jednak na warstwie sprawdzeń jednostkowych i integracyjnych, które tak naprawdę są najważniejsze w naszym codziennym developmencie. Wynika to z prostego faktu, że weryfikują one funkcjonalność w oparciu o surowy kod źródłowy, nie wymagający żadnej kompilacji czy uprzedniej modyfikacji. Wykonujemy je przy użyciu narzędzi Jest lub Vitest, chociaż z powodu większej nowoczesności i ogólnej wydajności, przy nowych projektach zalecamy to drugie.

Warto w tym miejscu zrobić pewną przerwę celem wyjaśnienia, co w HL Tech rozumiemy pod pojęciem testów jednostkowych i integracyjnych. Internetowa wiedza jest bowiem bardzo niejednoznaczna w tym zakresie i powoduje sporo niejasności nawet dla doświadczonych developerów.

Otóż testami jednostkowymi nazywamy sprawdzenie wyników działania pewnej zamkniętej logiki. Chodzi tutaj o proste funkcje, które przy użyciu takich samych argumentów na wejściu zawsze dadzą te same wyniki końcowe. Dobrym przykładem może być mapper, walidator, czy wszelki helper operujący na ograniczonym zakresie wejścia. W takich scenariuszach sprawdzamy możliwie wszystkie kombinacje danych wejściowych, czasami wywołując je manualnie, a czasami próbując wykorzystać pewną reużywalność.

describe('isInRange', () => {
    it.each<{value: number; result: boolean}>([
        {value: -2, result: false},
        {value: -0, result: false},
        {value: 0, result: false},
        {value: 0.1, result: true},
        {value: 5, result: true},
        {value: 9.9, result: true},
        {value: 10, result: false},
        {value: 15, result: false},
    ])('returns $result if value is $value', ({value, result}) => {
        expect(isInRange(value)).toBe(result);
    });
});

Przykład kodu testu jednostkowego.

Testami integracyjnymi w naszym ekosystemie nazywamy natomiast wszystkie testy oparte o renderowanie komponentu w środowisku JSDOM. W tej warstwie krytycznie ważne jest zrozumienie, na czym polega ta tytułowa integracja. W świecie frontendu wciąż obecne jest bowiem błędne przekonanie, że dotyczy ona połączeń pomiędzy częściami kodu – komponentami. Jednak takie podejście powoduje uzależnienie testów integracyjnych od szczegółów implementacyjnych, czyniąc je niemiarodajnymi i ciężkimi do utrzymania w przyszłości. W naszych projektach natomiast uznajemy każdą stronę w aplikacji za samostanowiącą całość, będącą najlepszym kandydatem do testów. W ich trakcie weryfikujemy, jak integrują się one z ich tzw. światem zewnętrznym – użytkownikiem czytającym dane na ekranie oraz korzystającym z aplikacji za pomocą myszki i klawiszy, adresem url w przeglądarce czy api, za pośrednictwem którego widok komunikuje się z backendem.

Testy takie opierają się na dokładnym symulowaniu sposobu, w jaki użytkownik korzysta z naszej aplikacji. Świetnie tutaj sprawdza się biblioteka user-event z funkcjami typu click() czy type() oraz Testing Library z selektorami, wśród których najważniejszym jest getByRole(). Integrację z adresem url realizujemy poprzez włączenie biblioteki obsługującej routing wewnątrz testowanego komponentu. W ten sposób jesteśmy w stanie sprawdzać aktualny adres url 'w przeglądarce’ i potwierdzać wystąpienie oczekiwanych przekierowań. Komunikację z backendem mockujemy natomiast przy użyciu MSW. W tym przypadku jesteśmy bardzo skrupulatni – obsługujemy tylko te endpointy, które powinny być wywołane w trakcie testu i tylko z danymi, które przewidujemy wysłać/odebrać z dokładnością od ostatniego znaku. Nic więcej, nic mniej, ponieważ jakiekolwiek odstępstwo od planowanej integracji z backendem powoduje niewłaściwe procesowanie operacji finansowych. Dla nas może się to szybko przerodzić w znaczące kary nałożone przez rynkowego regulatora.

Testy integracyjne dzielimy na dwa etapy – Happy path i Negative path. Te pierwsze służą potwierdzeniu czy wyświetlane są wszystkie oczekiwane elementy i przejściu przez wszystkie akcje zmierzające do – najogólniej mówiąc – osiągnięcia sukcesu. Dobrym przykładem może być wypełnienie formularza i wysłanie danych zakończone poprawną odpowiedzią z serwera. Drugi etap natomiast humorystycznie nazywamy 'ścieżką zdrowia’, podczas której sprawdzamy zachowanie komponentu przy błędnych odpowiedziach z endpointów, czy niewłaściwych danych wprowadzanych przez użytkowników.

Tutaj muszę się przyznać, że powyższy opis jest tylko zajawką tematu, ponieważ testy integracyjne same w sobie są materiałem na sporej wielkości publikację. Umiejętność pisania miarodajnych, wydajnych i czytelnych scenariuszy jest więc wynikową żmudnego szlifowania warsztatu, poznawania dobrych praktyk i rozumienia całego ciągu zdarzeń wywoływanych każdą akcją na testowanym komponencie. Niestety, naturalna skłonność do korzystania ze skrótów bardzo często kończy się tworzeniem nieefektywnych scenariuszy. Sprawia to kłopoty nawet średnio-zaawansowanym developerom. Moją radą w takiej sytuacji jest cierpliwość i koncentracja na najdokładniejszym symulowaniu sposobu, w jaki użytkownik korzysta z testowanego komponentu. Reszta przyjdzie z czasem.

it('redirects client to /profile after successful sign up', async () => {
    // Given data used during test scenario
    const login = 'test-login';
    const password = 'test-password';
    const csrfToken = 'test-csrf-token';
    // And handler for POST /login endpoint successful call
    // Note: it handles api endpoint requested only with given requestBody definition
    server.use(loginHandler({login, password, csrfToken}, {isAuthenticated: true}));
    // And url to redirect to after successful sign up
    const redirectionUrl = '/profile';
    // When component renders
    // Note: render helper wraps View with open source libraries like React Router or React Query
    // It also starts the page within a /login url context and provides csrfToken to be mocked internally 
    const {history} = renderPageWithinContexts(<LoginView />, {path: '/login', csrfToken});
    // Then main header is displayed
    expect(await screen.findByRole('heading', {name: /log in to see your profile/i}));
    
    // When client fill a sign-up form
    await userEvent.type(screen.getByRole('textbox', {name: /login/i}), login);
    await userEvent.type(screen.getByRole('textbox', {name: /password/i}), password);
    await userEvent.click(screen.getByRole('button', {name: /sign up/i}));
    // Then they are redirected to /profile page
    await waitFor(() => expect(history.location.pathname).toEqual(redirectionUrl));
});

Przykład kodu testu integracyjnego hipotetycznej strony do logowania.

Testowanie działania aplikacji

O ile poprzednia warstwa testów opiera się na sprawdzaniu wycinków aplikacji – jednostek logicznych, widoków czy stron, tak teraz skupiamy się na weryfikowaniu tzw. user journeys – realnych scenariuszy, koncentrujących się na osiągnięciu przez klienta oczekiwanego rezultatu. Do takiej weryfikacji najczęściej przydaje się nam Playwright. Testuje on produkcyjny bundle aplikacji wygenerowany lokalnie (testy funkcjonalne), lub zdeployowany na środowiska testowe (testy end-to-end / e2e).

Testy funkcjonalne najlepiej sprawdzają się w tzw. aplikacjach krokowych, gdzie klienci osiągają swój cel przez przejście kilku widoków tworzących razem ich tzw. journey. Za przykład może tutaj posłużyć tworzenie przelewu finansowego, który w większości systemów polega na wprowadzeniu danych, potwierdzeniu ich na podsumowaniu, wpisaniu kodu bezpieczeństwa i końcowym wysłaniu zgłoszenia do instytucji finansowej. Natomiast w przypadku aplikacji jednokrokowych, np. paneli przeznaczonych dla pracowników operacyjnych, które przypominają warstwę widoku dla operacji CRUD (create, read, update, delete), testy takie są niemal jednolite z naszymi testami integracyjnymi. Na tym etapie komunikacja z endpointami także jest zamockowana, a sama aplikacja testowana jest z użyciem prawdziwej przeglądarki, czego implementacją zajmuje się najczęściej Playwright.

Testy e2e skupiają się z kolei na zweryfikowaniu regresji krytycznych ścieżek w aplikacji. Za ich tworzenie odpowiedzialni są inżynierowie QA czy też tzw. testerzy. Jednak dzięki użyciu wspólnego języka Typescript i narzędzia Playwright, ich praca może być wykonywana lub weryfikowana także przez developerów frontendowych. Warstwa ta komunikuje się z prawdziwymi serwisami backendowymi, dzięki czemu dokonujemy regresji całości rozwiązania. Testy takie wykonują się każdorazowo po wdrożeniu zmian do głównej gałęzi jakiegokolwiek z komponentów ekosystemu (backend, frontend itp.).

Coś więcej niż testowanie kodu

Jeśli miałbym w jednym zdaniu opisać świat frontendu na przestrzeni kilku ostatnich lat, to nie zawahałbym się użyć słów – bardzo dynamiczny rozwój. Tworzenie tzw. 'ładnych widoczków’ już dawno odeszło do lamusa. W dzisiejszych czasach na froncie skupiamy się bowiem także na semantyce kodu(aby być zgodnym ze standardami SEO), dbamy o wydajność aplikacji, które powinny jak najszybciej wyświetlać klientom oczekiwane dane, czy z uwagą obserwujemy metryki świadczące o – najogólniej mówiąc – komforcie i bezpieczeństwie związanym z korzystaniem z aplikacji. A to tylko drobny wycinek naszych codziennych odpowiedzialności.

Sprawdzenie tego wszystkiego także można zautomatyzować. 'Ładne widoczki’ potwierdzamy poprzez testy wizualne z użyciem Playwright. Polegają one na tworzeniu tzw. snapshotów stron, które następnie zapisywane są do formatu graficznego. W ten sposób możemy potwierdzić, jak strona będzie wyglądać w przeglądarce i czy nie będziemy przypadkowo wprowadzać nieoczekiwanych zmian wizualnych. Metryki związane z wydajnością aplikacji, dobrymi praktykami czy zgodnością z SEO weryfikujemy natomiast poprzez automatyczne audyty snapshotów wykonane w Lighthouse.

Testowanie accessibility

Accessibility to temat niezwykle dla nas ważny. Oprócz wchodzącej w połowie 2025 roku w życie dyrektywy EAA, nakładającej obowiązek spełnienia standardów dostępności usług cyfrowych dla osób z niepełnosprawnościami, po prostu wymaga tego od nas ogromna liczba naszych najcenniejszych klientów.

Oczywiście najbardziej miarodajne testy accessibility są wykonywane przez prawdziwych użytkowników, podobnie jak testy ogólnego User Experience. Jednak część sprawdzeń jesteśmy w stanie zautomatyzować już na wczesnym etapie developmentu. Zwłaszcza jeśli mowa tutaj o standardach dotyczących generowanego kodu HTML – jego semantyki pozwalającej na lepszą integrację z assistive technologies, czy odpowiednio ułożonego wyglądu w zakresie użytych kontrastów, wielkości elementów itp.

Analizę statycznego kodu i wyglądu włączyliśmy do grupy tzw. testów snapshotów. Jesteśmy tutaj bardzo restrykcyjni i w nowych projektach nie pozwalamy na wprowadzenie żadnej zmiany, jeśli wykryty zostanie jakikolwiek błąd niezgodny z najpełniejszymi wytycznymi WCAG. Testowanymi aplikacjami sterujemy przy użyciu Playwright, po czym ich efekt analizujemy w Lighthouse i skanerami Axe.

public async assertSnapshots(snapshotTitle: string) {
    await Promise.all([
        this.assertAccessibilityChecks(snapshotTitle),
        this.performVisualSnapshotComparison(snapshotTitle),
        this.performAriaSnapshotComparison(snapshotTitle),
        this.performLighthouseFlowSnapshot(snapshotTitle),
    ]);
}
 
private async assertAccessibilityChecks(snapshotTitle: string) {
    // Perform static a11y analysis of given page (snapshot)
    const accessibilityChecks = await new AxeBuilder({page: this.page})
        .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
        .analyze();
    // Attach checks into test report
    await this.testInfo.attach(this.composeA11yReportName(snapshotTitle), {
        body: JSON.stringify(accessibilityChecks, null, 2),
        contentType: 'application/json',
    });
    // Ensure no a11y errors
    expect(accessibilityChecks.violations).toEqual([]);
}

Typy testów snapshotów oraz przykład wywołania statycznej analizy Axe.

Oprócz tego dublujemy scenariusze testujące krytyczne ścieżki client journeys, nawigując wyłącznie przy użyciu klawiatury. W tym celu także posługujemy się Playwright, natomiast przypadki testowe skupiają się bardziej na weryfikowaniu aktualnie zaznaczonych elementów oraz wywoływaniu na nich akcji przy użyciu przycisków na klawiaturze. W ten sposób potwierdzamy, że nasze usługi dostępne są także dla użytkowników korzystających z tzw. assistive technologies.

Wszystko powyżej to tylko zajawka

Bez dwóch zdań, testowanie frontendów to ciężki kawałek developmentu. Niejednokrotnie najprostsze rozwiązania okazują się złym patternem, jak np. identyfikowanie elementów po strukturze HTML, czy poprzez specjalny atrybut data-test-id. Z drugiej strony funkcja getByRole() z Testing Library z racjonalnych powodów technologicznych nie grzeszy wydajnością. W ten sposób znajomość wszelkich tips&tricks zmierzających do jej zwiększenia staje się swoistym weryfikatorem dojrzałości w zakresie pisania testów. A z każdym dniem okazuje się, że można poprawić coś jeszcze – aby scenariusze nie tylko były odporne na szczegóły implementacyjne aplikacji, ale też na elementy losowości danych, kolejności wystąpienia akcji czy konfiguracji środowisk na których są wykonywane.

Tematy te od lat omawiamy na naszych wewnętrznych meetupach, dzięki czemu z roku na rok potrafimy tworzyć testy coraz lepsze jakościowo. Zdajemy sobie sprawę, że wydłuża to czas developmentu funkcjonalności. Nie przesadzam stwierdzając, że napisanie wszystkich testów do nowej funkcjonalności zajmuje nieco więcej czasu niż napisanie jej samej. Co jednak osobiście doceniam w codziennej pracy w HL Tech, to to, że biznes jest świadomy wartości testów automatycznych i nigdy nie zadaje pytań o możliwość zastosowania jakiś półśrodków. Na rynku finansowym weryfikowalność jest na szczęście jedną z najważniejszych odgórnych regulacji.

The post Jak pisać efektywne testy frontendów? appeared first on HL Tech.

Ciekaw jestem, ilu z Was pamięta swoje pierwsze, szkoleniowe projekty developerskie. Ich celem było nauczenie podstaw różnorodnych zagadnień. Na przykład podłączenia się do źródła danych, bezpiecznej obsługi ich na backendzie, czy tworzenia schludnego widoku dla klienta. Nawet jeśli poszliście o krok dalej i już staraliście się stosować separację warstw w Waszej aplikacji, najpewniej i tak wszystko to znajdowało się w jednym projekcie, w jednym repozytorium.

W tamtym momencie nawet nie zdawaliście sobie sprawy, że jesteście świadkami narodzin kolejnego monolitu – struktury ściśle połączonych ze sobą elementów całej aplikacji. Oczywiście nie stanowiło to żadnego problemu, ponieważ projekt ten służył Wam do nauczenia się czegoś nowego. Na wiedzę związaną z architekturą czas miał przyjść nieco później. Niemniej wiele lat temu w podobny sposób stawiano fundamenty praktycznie każdej aplikacji. Z czasem nad ich monolitycznym kodem zaczęło pracować coraz więcej developerów, a projekty rozrastały się do niebotycznych rozmiarów.

Pierwsze mikroserwisy

Dlatego w pierwszych latach obecnego wieku zaczęło formować się pojęcie mikroserwisów. Jest to koncept architektoniczny, zgodnie z którym aplikacja składa się z wielu usług, o bardzo wąskiej odpowiedzialności. Zazwyczaj zamykają się one w jednej domenie biznesowej.

W ten sposób większe aplikacje zaczęły przyjmować formę zbioru modułów, a działy developerskie – zespołów domenowych lub produktowych. Pozytywnie wpłynęło to na łatwość tworzenia oprogramowania i ogólną wydajność pracy zespołów. Ich praca odbywała się w niemal całkowitej separacji. Developerzy mogli skupiać się na swoim wycinku biznesu, nie martwiąc się o funkcjonowanie całości.

Monolity zbudowane z twardej skały

Niestety, pomimo niewątpliwych zalet takiej architektury większość dużych organizacji do dziś obciążona jest jakąś formą monolitu. Zazwyczaj są to najstarsze i najważniejsze części systemu. Po ich utworzeniu zazwyczaj nie ma potrzeby żadnej modyfikacji. Wymagają one jedynie prac utrzymaniowych związanych np. z aktualizacją wersji wykorzystywanego oprogramowania.

Oczywiście, większość produktów, nad którymi pracujemy w HL Tech to zazwyczaj nowe funkcjonalności, ale niektóre zespoły mają okazję zetknąć się także z kodem napisanym kilkanaście lat temu. W takim przypadku naszym zadaniem jest odłupanie części monolitu i bezpieczne przeniesienie go (czyt. zazwyczaj przepisanie) do osobnego modułu. Przypomina to trochę operację na żywym organizmie. Dlatego przed przystąpieniem do prac trzeba poświęcić sporo czasu na dokładne poznanie funkcjonującego już produktu. I tutaj bonus. Poprzez kontakt z kilkunastoletnim kodem mamy doskonały podgląd na efekt historycznych decyzji – tych dobrych, ale z perspektywy czasu też tych nietrafionych. Jest to dla nas bardzo rozwojowe doświadczenie, ponieważ obserwacji takich nie da się szybko poczynić na projektach pisanych od zera.

Granulacja na frontendzie

Podejście z dzieleniem na mniejsze stosujemy także w mojej specjalizacji – na frontendzie. No bo pomyślcie — użytkowników systemu zazwyczaj można podzielić na kilka grup, a każda z nich będzie korzystała z innej jego części. Czy nie brzmi to jak dobry sposób podziału platformy na moduły? W ten sposób wchodzimy w temat architektury mikro-frontendów. Około 4 miesiące temu wraz z Łukaszem Fiszerem miałem okazję dokładniej ją zaprezentować podczas Dev.js Summit 2022.

Architektura mikro-frontendów bez dwóch zdań wspomaga wydajność codziennej pracy developerów. Dla klientów i ich potrzeb jest z kolei niewidoczna. Nie wpływa bowiem na łatwość czy szybkość działania aplikacji. Na szczęście śledząc nowinki ze świata developmentu widać, że pojawiające się technologie coraz lepiej wspierają także te potrzeby. Przyjrzyjmy się części z nich.

Pobieraj tylko to, co użytkownik aktualnie potrzebuje

Nowoczesne aplikacje frontendowe w większości wykorzystują podejście zwane Client Side Rendering (CSR). Oznacza to, że wchodząc na wskazany adres url, przeglądarka najpierw pobiera cały kod Java Script, a następnie generuje widok strony.

Niestety produkcyjne wersje większości aplikacji pisanych w React to tak naprawdę dwa duże pliki Java Script. Wymusza to na kliencie pobranie całego kodu, włącznie ze stronami, których być może nawet nie ma zamiaru przeglądać. Powoduje to nadmierny ruch w Internecie, a wyliczenia na większym zakresie danych opóźniają moment wyświetlenia widoku.

Jednym z łatwiejszych i popularniejszych usprawnień tego procesu jest podejście zwane lazy loading. Polega ono na tym, że w momencie wejścia na stronę, przeglądarka pobiera tylko to, co jest potrzebne do jej wyświetlenia – kod frameworka i aktualnego widoku. W ten sposób można przyspieszyć start aplikacji nawet o kilkaset milisekund.

Rendering odmieniony przez wszystkie przypadki

Gdy zorientowano się, że mniejsza liczba wyliczeń Java Script przyspiesza start aplikacji, zaczęto zadawać sobie pytanie: czy aby na pewno wyświetlenie każdego elementu musi być efektem działania skryptu? Okazało się, że nie. Proces ten można usprawnić, w czym pomogło podejście Island architecture.

Zgodnie z nim widok każdej strony można podzielić na odizolowane od siebie obszary. Za przykład niech posłuży stopka aplikacji. Jest ona niezależna od całej reszty, a dodatkowo przez miesiące nie podlega żadnym zmianom, wygląda i działa dokładnie tak samo na każdej z podstron. To otwiera drogę do techniki Server Side Rendering (SSR) w jej najbardziej wydajnym kształcie. Zgodnie z nią serwer tylko raz generuje statyczny kod HTML komponentu i każdemu klientowi wysyła zapisany w wewnętrznej pamięci efekt tej operacji. W ten sposób przeglądarka klienta nie musi wykonywać kosztownych wyliczeń Java Script, otrzymuje finalny kod, który może bezpośrednio wyświetlić na ekranie.

Zagadnienie to można rozszerzyć nawet na całe strony. Zwłaszcza te, które nie wymagają bieżącej komunikacji z backendem. Świetnie sprawdza się to w obszarach podobnych do blogów – artykułach, elementach typu Frequently Asked Questions czy prezentacyjnych kartach produktu. W takim przypadku generujemy kod HTML całej strony i tym samym niemal do zera ograniczamy czasochłonne wyliczenia Java Script po stronie klienta. To podejście nazywamy Static Site Generation (SSG).

Inne sposoby na lepszą wydajność

Lazy loading przyspiesza czas wyświetlenia widoku dzięki rezygnacji z pobierania danych aktualnie nam niepotrzebnych. Gdy jednak klient chce wejść na inną stronę, jej kod musi zostać dociągnięty z serwera. Na szczęście nowe trendy na rynku pozwalają na przyspieszenie tego procesu w taki sposób, że staje się on prawie niezauważalny.

Ciekawe i wielopoziomowe rozwiązanie dostarcza nowy framework o nazwie Remix. Przykładowo — jego twórcy zauważyli, że od czasu najechania kursorem myszy nad przycisk, do jego naciśnięcia przez użytkownika, zwyczajowo mija kilkaset milisekund. Jeśli przycisk ten odpowiada za przejście do nowej strony, kod z nią związany możemy zacząć pobierać już na akcji hover, zamiast – jak dotychczas – na akcji click.

Framework udostępnia też możliwości łatwego sterowania zaawansowanym keszowaniem. Dzięki temu treści statyczne (np. grafika, CSS, HTML) odkładane są w punktach dostępowych Content Delivery Network (CDN). W przypadku dostawców o rozbudowanych sieciach, punkty wejściowe do niej mogą znajdować się nawet w kilku miejscach kraju. Oznacza to, że jeśli jakiś klient wszedł na daną stronę, każdy kolejny z jego okolicy dostęp do tej samej treści uzyska już w przeciągu kilkudziesięciu milisekund.

Jeśli jednak musimy wyświetlić dane „na żywo”, wymagające ciągłej komunikacji z serwerem, Remix architektonicznie faworyzuje wspomnianą wcześniej Island architecture. W ten sposób każda część strony wywołuje zapytanie po dane niezbędne do wyświetlenia w jej obszarze. Żądanie inicjuje się natychmiastowo, wykonuje w sposób równoległy, a pobrane dane pojawiają się w widoku niezależnie od siebie.

Wszystkie te zabiegi mają jeden wspólny cel — zmniejszenie czasu od wejścia na stronę do wyświetlenia zgromadzonych na niej danych. Tam, gdzie można, klient otrzymuje wygenerowaną wcześniej statyczną treść. Natomiast funkcjonalności wymagające wyliczeń na serwerze są istotnie przyspieszone, a czas spędzony na ich przeprocesowanie blokuje tylko niewielkie części aplikacji.

Dziel i bądź wydajny

Wszystko to pokazuje jak dzielenie na mniejsze zakresy i odpowiedzialności, pozytywnie wpływa na całościową wydajność. Co ciekawe, zasada ta zdaje się sprawdzać wszędzie.

Od strony organizacyjnej — pracując w jednej domenie, nie muszę znać i rozumieć wszystkich zasad biznesowych obowiązujących w firmie. Zaczynając nowy projekt, proces jego produkcji staram się podzielić na etapy, a te następnie na mniejsze zadania. Dzięki temu łatwiej jestem w stanie zrozumieć każdy ich aspekt, wiarygodnie wycenić czas realizacji a prace zamknąć w regularne sprinty.

Od strony specjalistycznej – jako frontend developer nie muszę znać wszystkich szczegółów z zakresu backendu, devops, bezpieczeństwa czy zarządzania bazami danych. Mogę skupić się na wysokiej specjalizacji w swoim technologicznym zakresie.

Od strony developerskiej — tworząc małe aplikacje, jestem w stanie bardzo szybko ogarnąć ich kod. Niewielka odpowiedzialność i tym samym poziom skomplikowania funkcjonalności pozytywnie wpływają na ich wydajność i bezpieczeństwo. W ten sposób mogę szybciej dostarczyć nowe rozwiązania i treści do naszych klientów.

The post Małe aplikacje – sposób na łatwiejszą pracę i szybsze dostarczanie nowych funkcjonalności appeared first on HL Tech.

HL Tech is a technology centre focused on providing cutting-edge software solutions for Hargreaves Lansdown – an award-winning investment service provider on the British Market. We believe in quality and innovation, that is why we implemented best practices into our daily workflow. But more than that, we are a team of specialists willing to learn and share knowledge.

Accessibility rules (pun intended) 

Implementation of Web Content Accessibility Guidelines 1.0 first published in 1999 and subsequent updates throughout the Internet was a long and painful process. People responsible for the creation of early websites often overlooked or were unaware of these rules. The Internet was still a new medium, and like all new things, it had its infancy problems.

Because of limited technological advancement companies and web designers alike reached for solutions such as Adobe Flash (back then owned by Macromedia) or rich imagery often using animated GIFs to convey their message. The goal was to stand out, be visible, even overly flashy. 

The downside? The content was not accessible by default to many people because screen readers struggled with reading Flash websites and images replacing text brought the same problem. Navigation through such websites was exhausting if not impossible for some who were not able to use computer mice or keyboard comfortably. The web, unfortunately, was mostly created for able-bodied people.

You may ask – why should we spend time thinking about the minority? Because all of us can be a part of it at any moment in our lives. 

A spectrum of permanent, temporary, and situational disabilities (credit: Microsoft’s Inclusive Design)

The simplest example – an injured arm. Good luck with using a website where you cannot use Tab key to jump around the content or purchase stuff from the online store where you need to manoeuvre with a mouse and activate each address field by a single click. 

That is why accessibility guidelines are not for a few, but everyone.

Shared responsibility

Although originally WCAG was aimed to be a guidebook for Web content developers and web-developers, the roles have shifted. Many new professions originated in the process of specialisation. Imagine a regular commercial website – we can positively assume that most of its design, search engine optimisation and content is not usually done by the same person.

Where lies the responsibility for making products accessible?

At ’HL Tech’ we understand that this is a shared responsibility, as it should be. Of course, some areas are better off being solved by developers, while others left for UI/UX designers. Still, we should all learn from each other. It is not uncommon for our teams to talk about ARIA (Accessible Rich Internet Applications) codes and design patterns used in our applications, naming conventions of the buttons or contrast.

Design system as an opportunity 

When we first began working on our design system we knew that expertise from many departments would come in handy. This year-long journey originated with three simple goals: user-friendliness, ease of use for developers and look consistent with our brand. Luckily we have many talents within the company – such as Aneta Górka, a Senior Front End Developer in the Design, UX & Optimisation department who gave a brilliant talk and hosted workshops on web accessibility to widen our horizons. Conversations have started, knowledge of our teams grew, and we took this opportunity to do the right thing and add accessibility requirements to our workflow.

Our design process usually consists of three steps: identifying a need for the new component, designing it in line with our brand and third, a crucial one, is code review with a team of front-end developers.

We care for the quality of our React elements base. Nothing will go unnoticed, whether it is contrast and size of the text, missing icon, validation rules, proper ARIA snippets or text. 

Together we created something we can rely on in our day-to-day work – we know the quality of our projects is top-notch.

Designs system help us to be more efficient.

When we finish our design and review process for a new element, we test it from many angles. Firstly, our design team checks if the proportions, colours, contrast, WCAG requirements, HTML structure and brand standards are in line with the designs, then it is tested in isolation by our skilled Front End team to make sure it also performs up to our high standards.

Our Field Text component has an option to visually hide input’s label while still being read by screen readers. 

Having this well-crafted library makes not only my job easier by having a working rendition of my design assets, but also is an easy way for developers to translate high-fidelity mockups into working products. It takes just one look to know which element needs to be used.

But most importantly, we do not have to worry if we broke some of the accessibility rules, one would need to try hard to do so.

TB

The post How we build an accessible design system at HL Tech appeared first on HL Tech.

QCon is a 3 day conference + 2 days of workshop. I attended the conference part. QCon is split to different tracks. Most of them are technical, but there are some concentrating on soft skills as well.

What I find interesting are Ask Me Anything sessions. Speakers from each track spent 1 hour answering questions from the audience. I attended some of them and the best one was Domain Driven Design AMA with Vaughn Vernon from Kalele, Indu Alagarsamy from Particular Software and Stuart Charlton from Pivotal. They shared their experience in implementing DDD in different companies. Even though I already participated in projects utilizing DDD approach, I think it is always good to hear what fellow developers went through and learn from their mistakes/success stories as well.

There were some nice presentations during the conference. First one belonged to “Modern CS in the real world” track. Talk of Colm MacCárthaigh was about PID loops and how they are used to keep AWS systems stable. PID loops measure system behavior after signal (of any kind) is sent to the system. Metrics are constantly gathered. Difference between expected and actual value is calculated and signal is so modified that the actual value gets closer to the expected one.  It was really interesting to see this mechanism used in modern IT systems to solve common problems in production environment.

First of them are open loops. They occur when actions take place in the system (of any kind) and consequences of these actions are not measured. The solution is to close the loop i. e. start constant measures of the consequences.

Second are power laws. They occur in systems, where there are many small elements cooperating with each other to provide greater value. Sample of such configuration are IT systems and microservices environment. When one of the systems fail for any reason, for example due to broken contracts between services (how to avoid this you can read about Judge Dredd, an Open Source framework for contract testing in [1]), errors cascade to direct neighbors and exponentially further to other services. According to Colm, compartmentalization is the best solution of this problem. More compartments mean relatively smaller blast radius.

There are some other problems like lags (old information is sometimes worse than no information which are sometimes hard to avoid (spiky loads etc.), false functions (misleading metrics and dependencies between them leading to wrong analysis – to avoid this situation it is advisable to base analysis on basic metrics like CPU), edge triggering which means switching mode when particular threshold of value of the metric is reached (in case of controlling the new mode often kicks in at a time of high-stress).

Another interesting subject for me was presented during “Software defined infrastructure: Kubernetes, service mesh and beyond” track. I would like to mention 2 presentations here. First one, “The Service Mesh: It’s about Traffic” by Oliver Gould from Linkerd, introduced the audience to the definition of service mesh – it is infrastructure layer for handling service-to-service communication. Service mesh does the following things: load balancing, service discovery, routing, tracing, handles traffic policies, secures service to service communication. Linkerd was described as sample implementation of the concept. It is worth mentioning that there are more than one solution implementing service mesh concept like Istio. In order to avoid dependency to one technology, Service Mesh Interface is introduced. It is API used to isolate concept of Service Mesh of corresponding implementations. Definition of this API and its features were nicely described by Brendan Burns (from Microsoft Azure and Kubernetes co-founder) in his talk “Introduction to SMI (the Service Mesh Interface)”.

One of the best features of QCon was sharing experience from success and failure stories by fellow senior developers, technical leaders and architects. Here I would like to mention “Time Predictions in Uber Eats” talk by Zi Wang, whereby he described how Uber uses machine learning to accurately predict delivery times, “Machine-Learned Indexes – Research from Google” by Alex Beutel, whereby he goes through resent research on using machine learning algorithms to improve traditional data processing systems, “Conquering Microservices Complexity @Uber With Distributed Tracing” by Yuri Shkuro, whereby he describes methodology and solution that uses data mining to learn typical behaviour of systems from massive amounts of distributed traces, compares it with pathological behaviour during outages, and uses complexity reduction and intuitive visualizations to guide the user towards actionable insights about the root cause of the outages. The solution is built using modules available in the open source as part of Jaeger (distributed tracing system developed by Yuri Shkuro himself), Uber’s distributed tracing platform and an incubating project at Cloud Native Computing Foundation.

Visiting New York and participating in QCon 2019 was a good decision I had a chance to participate in many interesting talks, meet fellow developers from American companies, discuss with them in Ask Me Anything sessions and listen to inspiring talks.

[1] https://dzone.com/articles/contract-testing-in-hl-tech-judge-dredd

The post QCon New York 2019 appeared first on HL Tech.

Potrzeba biznesowa a realizacja projektu

Dział obsługi klienta w Hargreaves Lansdown potrzebował intuicyjnej, przejrzystej i szybkiej aplikacji, która poprawi efektywność obsługi klienta przy jednoczesnym braku zmiany procesów i procedur. Aplikacja miała zastąpić jedną z wielu funkcji systemu służącego do obsługi klienta w ramach dużego projektu, którego celem jest podzielenie dużej monolitycznej aplikacji na mniejsze komponenty. W ten sposób chcieliśmy ułatwić i uniezależnić rozwój poszczególnych funkcji systemu.

Spośród projektów możliwych do realizacji został wybrany taki, który mógł być zrealizowany w okresie trzymiesięcznych praktyk – przygotowanie aplikacji dla działu obsługi klienta w siedzibie Hargreaves Lansdown w Bristolu. Następnie wybraliśmy technologię, w ramach których będzie realizowany projekt – wszystko po to, aby przygotować dwutygodniowe szkolenie.

W projekcie uczestniczyło dziesięciu praktykantów oraz product owner będący reprezentantem biznesu i określający oczekiwania wobec aplikacji. Ja z kolei pełniłem rolę opiekuna technicznego i merytorycznego. W projekt zaangażowany był także software development manager oraz wielu innych programistów, którzy szkolili praktykantów.

System był rozwijany iteracyjnie przy użyciu Scruma. Każda iteracja miała demo, którego celem było przedstawienie użytkownikom efektów pracy w poprzedzającej iteracji oraz zebranie informacji zwrotnej. Taki proces wymuszał ciągłą gotowość do wprowadzania zmian w kolejnych iteracjach, aby było to możliwe musieliśmy zadbać o wysoką jakość kodu oraz testów.

Kandydat idealny, czyli jaki

Implementacja aplikacji a następnie wdrożenie na produkcję jest bardzo dużym wyzwaniem dla osób bez doświadczenia. Co więcej praca przy takim projekcie w zespole składającym się z 10 osób jest sama w sobie wyzwaniem i wymaga sprawnej komunikacji w zespole. W związku z tym w czasie procesu rekrutacji skoncentrowaliśmy się na kilku cechach, które dla nas były kluczowe.

• Po pierwsze: determinacja i zaangażowanie członków zespołu, ponieważ są to elementy ułatwiające pracę w projekcie, który ma określone wymagania funkcjonalne, jakościowe oraz ramy czasowe.
• Po drugie: otwartość i przyjazne nastawienie, ponieważ cechy te znacznie ułatwiają komunikację, wymianę wiedzy i doświadczeń.
• Ponadto ceniliśmy u kandydatów także zainteresowanie tematyką wytwarzania oprogramowania (bazy danych, projektowanie, technologie web itp.).

Naszym zdaniem dobry inżynier oprogramowania powinien nie tylko znać dobrze język programowania czy bibliotekę, ale również umieć wymienić wiedzę z kolegą z zespołu, omówić problem z product ownerem, czy dobrze uargumentować swoje wybory podejmowane odnośnie rozwiązań informatycznych.

Technologie, które wykorzystaliśmy

Aplikacja została podzielona na dwa komponenty – frontend, stanowiący interfejs użytkownika oraz backend wystawiający API dla frontendu, zawierający logikę biznesową, element integracji z bazą danych oraz systemami uwierzytelniania użytkownika. Komponent frontendu komunikował się z backendem przy pomocy Fetch API, co zapewniało asynchroniczną komunikację. Fronted i backend miał odrębne repozytoria kodu źródłowego, dzięki czemu można było zastosować dopasowane do potrzeb technologie, biblioteki, narzędzia zarządzania zależnościami czy procesy budowania i wdrażania.

Zarówno frontend jak i backend był wdrażany na środowisko Kubernets, które automatycznie zarządzało zasobami takimi jak interfejsy sieciowe, procesory, pamięć RAM itp. Komponenty były dostarczane jako kontenery Docker’owe, a każda zaimplementowana i zaakceptowana przez zespół funkcja aplikacji była automatycznie wdrażana przy pomocy Jenkins’a, czyli narzędzia realizującego wcześniej skonfigurowany potok. Jego kluczowe etapy to: kompilacje, testowanie, przygotowywanie i budowanie paczki zawierającej działającą aplikację, przygotowywanie kontenera Docker i ostatecznie wdrażanie kontenera na środowisko Kubernetes.

Implementacja logiki biznesowej w komponencie backend była realizowana przy wykorzystaniu języka Java i Spring Boot (ułatwiający konfigurację samodzielnej aplikacji). Backend wymagał integracji z bazą danych przy użyciu Spring Data JPA oraz Hibernate. Aby ograniczyć komunikację z bazą zastosowaliśmy cache L2 oraz cache zapytań. Z kolei chcąc ograniczyć dostęp do aplikacji i zapewnić uwierzytelnianie oraz autoryzację użyliśmy Spring Security. Spring MVC posłużył nam do wystawienia metod HTTP dla aplikacji fronted. Testy integracyjne i jednostkowe były pisane przy użyciu Spock’a wykorzystującego język Groovy.

Frontend jako interfejs graficzny był realizowany przy użyciu technologii Web. Całość składała się z wielu małych komponentów takich jak przyciski, etykiety, pola tekstowe, pola rozwijane z automatycznym uzupełnianiem itp. Jako języka programowania użyliśmy Typescript’u, który jest „transpilowany” do Javasriptu. Jego kluczową zaletą jest statyczne typowanie, co umożliwia wykrywanie wielu błędów na etapie kompilacji oraz znacząco poprawia czytelność kodu. Wykorzystaliśmy także bibliotekę React oraz Material UI, co znacząco przyspieszyło implementację. Architektura Redux zakłada jednokierunkowy przepływ danych. Wywołania backendu są realizowane asynchronicznie przy użyciu Fetch API. Do zarządzania zależnościami i budowania aplikacji użyliśmy Yarna, Npm’a i Webpacka.

Postęp w pozyskiwaniu wiedzy i umiejętności

W okresie trzymiesięcznych praktyk w każdej kolejnej iteracji widać było postęp i większą samodzielność w tych obszarach. Pod koniec członkowie zespołu znacznie sprawniej radzili sobie w trakcie analizy i planowania, potrafili przewidzieć szereg konsekwencji przy wyborze konkretnego rozwiązania. Efektem tego był wzrost ilości proponowanych zmian oraz samodzielnie dostarczanych funkcji.

Podsumowując, do programu praktyk zaprosiliśmy 10 osób, które nie miały wcześniej żadnych doświadczeń zawodowych poza działaniami podejmowanymi w związku ze studiami lub  programowaniem we własnym zakresie. Dzięki ogromnemu zaangażowaniu i chęci uczenia się, zespół wykorzystał w pełni możliwości, jakie stwarzał program praktyk – a my przekonaliśmy się, że w tych osobach tkwi ogromny potencjał. Dlatego zdecydowaliśmy się kontynuować współpracę z chłopakami.

Co dalej?

Aplikacja wytworzona przez praktykantów przygotowywana jest do wdrożenia, a my implementujemy kolejne funkcjonalności. Praktykanci dołączyli do innych zespołów projektowych, gdzie będą mieli okazję zapoznać się z kolejnymi technologiami i pracować z doświadczonymi programistami.

The post Program praktyk okiem programisty: nowoczesne technologie i realny projekt appeared first on HL Tech.