Jak utrzymujemy jakość akademii za pomocą wizualnych testów regresji?

Ostatnio wprowadziliśmy nasz nowy interfejs akademii. Podczas prac nad nim zaczęliśmy korzystać z nowych technik, które pomogły nam usprawnić przepływ pracy i utrzymać wysoki standard jakości naszego produktu. Zapobiegamy występowaniu błędów, pracując w sposób oparty na komponentach i często testując niezamierzone zmiany wizualne (regresje wizualne).

Rozwój oparty na komponentach

W ostatnich latach dużym trendem w rozwoju interfejsów użytkownika jest rozwój oparty na komponentach (CDD). Komponenty to najmniejsze elementy samodzielnej funkcjonalności, które same w sobie stanowią wartość dodaną. CDD zakotwicza się w tym, tworząc proces kompilacji, który działa od dołu do góry. Najpierw tworzysz małe komponenty, które łączą się z większymi komponentami, które razem tworzą funkcję lub stronę. Pomyśl o tym jak o rowerze składającym się z mniejszych części. Zaczynasz od stworzenia dwóch kół, a następnie ramy. Dodaj kierownicę, pedały i łańcuch. Teraz zaczyna to wyglądać jak rower. W ten sposób opracowaliśmy również interfejs akademii.

Doświadczamy wielu korzyści z pracy w sposób oparty na komponentach:

• Komponenty są wielokrotnego użytku. Jeśli zbudujesz koło, możesz użyć go do zbudowania większego lub mniejszego roweru, a może nawet trójkołowca.

• Małe komponenty są łatwe do zrozumienia.

• Komponenty są łatwe do przetestowania. Możesz przetestować, czy koło działa, nie musisz się jeszcze martwić o cały rower.

• Praca z komponentami często przyspiesza nasz proces rozwoju, zapewniając rozwiązania typu plug and play.

• Rozwój jest skoncentrowany. Łatwo jest śledzić warianty komponentów.

• Dostępne są narzędzia pozwalające łatwo śledzić wszystkie dostępne komponenty, które zostały stworzone przez współpracowników.

• Skorzystanie z komponentów jest bardzo proste.

Niektóre przykłady komponentów, które stworzyliśmy to: przycisk, wyskakujące okienko, odpowiedź wielokrotnego wyboru, a także kompletna strona logowania.

Storybook pozwala nam rozwijać komponenty poza naszą aplikacją w odizolowanym środowisku, nie martwiąc się o zależności lub zepsucie aplikacji.

Historia naszego interfejsu w Storybook

Po utworzeniu wielu komponentów, które są podstawą naszego interfejsu, organizujemy je w Storybook. Storybook to eksplorator komponentów lub biblioteka komponentów. Jest to skuteczny sposób na śledzenie wszystkich naszych komponentów. Każdy komponent otrzymuje własną historię w Storybook, gdzie można przeglądać wszystkie możliwe warianty komponentu: 

Button component in Storybook

Na przykład w przypadku komponentu przycisku możliwe jest wyświetlenie przycisku domyślnego, podniesionego, niepodniesionego i wyłączonego. Możliwa jest również interakcja z komponentem, aby zobaczyć, jak zmienia się jego stan lub zachowanie. Można na przykład wpisać coś w formularzu logowania, a pola wejściowe poinformują, czy wprowadzone dane są prawidłowe:

Login form component in Storybook

Storybook pozwala nam rozwijać komponenty poza naszą aplikacją w odizolowanym środowisku, nie martwiąc się o zależności lub zepsucie aplikacji.

Używamy Storybooka jako narzędzia do projektowania, ponieważ przyjęliśmy strategię projektowania opartą na historii. Kiedy projektujemy, bezpośrednio tworzymy coś, co jest wartościowe. Zamiast tworzyć marnotrawstwo w Photoshopie, jak to robiliśmy wcześniej. Kiedy dodajemy historie komponentów do Storybook, automatycznie współtworzymy żywy przewodnik po stylach lub bibliotekę interfejsu użytkownika. Oznacza to, że deweloper może łatwo wybierać z szerokiej gamy gotowych komponentów, aby dodać je do tworzonej funkcji. Dzięki temu nasz interfejs jest spójny i stosunkowo tani w rozwoju:

Login page component in Storybook

Za pomocą dodatków rozszerzyliśmy Storybook, abyśmy mogli przetestować dostępność każdego komponentu. Upewniając się, że interfejs pozostaje dostępny dla użytkowników z pewnymi ograniczeniami:

Accessibility checking in Storybook

Wizualne testy regresji przy użyciu Percy

Wcześniej mówiliśmy o regresjach wizualnych, które są niezamierzonymi zmianami wizualnymi. Aby uświadomić sobie te zmiany wizualne, używamy narzędzia o nazwie  Percy. Percy to narzędzie do testowania regresji wizualnej, które dba tylko o integralność wizualną.

Dzięki Storybook mogę budować i stylizować komponenty w izolacji i zawsze mam wgląd w różne scenariusze, które zaprojektowałem. Z pomocą Percy'ego zawsze wiem, jaki wpływ mają wprowadzane przeze mnie zmiany.
Anouk
Front-End Developer & UX Designer

>

Dla każdego komponentu, który opracowaliśmy w naszej bibliotece komponentów Storybook, tworzony jest zrzut ekranu. Kiedy zmieniamy komponent, tworzony jest nowy zrzut ekranu, a oba są porównywane obok siebie. Różnice są następnie zaznaczane na czerwono, aby wyraźnie pokazać, co się zmieniło:

Regressions made visible in Percy

Differences between the old and new version are marked in red

Percy łączy się bezpośrednio z naszym potokiem ciągłej integracji (przepływ od pomysłu do rzeczywistości), powiadamiając nas o wizualnych regresjach przed wprowadzeniem zmian. Po sprawdzeniu przez jednego z projektantów, zmiany są akceptowane lub odrzucane. Percy pozwala również na dyskusję na temat danej zmiany:

Percy integrated into our pipeline telling us something needs review

Wszystko to pomaga nam powstrzymać niechciane zmiany wizualne przed dotarciem do Ciebie, naszych użytkowników końcowych. Czy mimo to zdarzyło się, że prześlizgnął się jakiś błąd wizualny? Czytaj dalej, aby dowiedzieć się, jak sobie z tym radzimy w tym artykule