Testowanie CSS

Jest rok 2020 - czy mamy coś sensownego do testowania CSS? rozwalających się layoutów?

Kiedyś poświęcałem czas na szukanie w google, ale już mi się nie chce - przyznaje się. Możliwe, że nie umiem szukać.

Nie interesuje mnie testowanie czy w CSS znalazła się jakaś reguła, ale wyników wyświetlania.

Minimum to coś w stylu:
dla testowanego CSS i danego HTML - wynik ma wyglądać jak na obrazku
Lepiej jakby jeszcze można było wygodnie zadawać jakie fragmenty obrazka są interesujące.
A ideał gdyby testować przy pomocy DSL jakieś reguły:

• tytuł ma być różowy,
• wiersze mają być od siebie oddalone o min 2px,
• tekst w zadanej sekcji nie może być ucięty...

jarekr000000 napisał(a):

Minimum to coś w stylu:
dla testowanego CSS i danego HTML - wynik ma wyglądać jak na obrazku

Czasami robię tak, że projekt graficzny wrzucam na warstwę, którą sobie jednym przyciskiem mogę włączać i wyłączać.

Jak się uprzesz, to w JS możesz zrobić skrina z całej strony i zapuścić porównanie piksel po pikselu z projektem.

Ale to i tak nie rozwiązuje problemu. Projekt dostajesz tylko w 2-3 rozdzielczościach, a jak ma działać dobrze, to trzeba zmieniając rozmiar okna, obserwować, jak się wtedy zachowują poszczególne sekcje i czy np. w zakresie pomiędzy 567px a 612px nie wyświetla się jakaś bzdura albo po prostu brzydko się nie układa. Nie wiem, czy coś takiego w ogóle można zautomatyzować.

Okej, to nie jest sensowna porada poparta doświadczeniem, to jest luźny pomysł, który wysnułem na podsatwie doświadczenia w innych dziedzinach wytwarzania oprogramowania.

Jakby nie patrzeć, CSS/layout to nie jest język programowania, więć nie specjalnie masz go jak przetestować - to trochę tak jakbyś chciał testować config webpacka. CSS jest wynikiem sam w sobie (tak, ludzie o tym myślą jak o programowaniu, bo pisze się kodem, ale to nie jest język programowania). Jak popatrzysz na to ogólnym okiem, to dostrzerzesz że CSS to tak naprawdę zbiór deklaracji, niektóre z nich są skomplikowane, niektóre wymagają zmiany dla różnych rozdzielczości, etc. A wiemy że wizualna regresja to zły pomysł, ponieważ nie zwraca uwagi na żadne konkretne rzeczy (jak unit testy) - tylko jest albo tak, albo tak.

Moim zdaniem, jedynym sensownym rozwiazaniem, dla kogoś kto przejmuje się utrzymywalnością layout'ów, to żeby uprościć CSS w jego implementacji - zdeklaratyzować go jeszcze bardziej (mniej więcej jak bootstrap/flex zdeklaratyzował float'y). Np, jeśli tworzysz apkę w progresywnych frameworkach (ng, react, vue), to możesz robić komponenty odpowiedzialne tylko za layout - najlepiej z małą ilością parametrów. I nie mam na myśli NavBar, Header, Footer, bo one są zbyt związane z domeną biznesową.

Mam na myśli np CollapsibleDiv, albo DesktopContainer/MobileContainer, ButtonWideOnMobile, MarginNoSmallerThan, CssBaseLine, etc. Np. taki Carousel wszystkie CSS z absolutami i kręceniem jest schowane w komponencie, i nie trzeba ich testować osobno. Ich jedyną. odpowiedzialnością byłoby budowanie latoutu, (tego o który chcesz dbać). Zawsze tam gdzie chciałbyś zbudować layout CSS'ami, używasz tych komponentów. Jeśli nie ma takiego którego chciałbyś użyć - tworzysz go. Takie poszczególne komponenty możesz unit testować np karmą/jest, a zbudowane z nich aplikacje nie będą wymagały testowania (wydaje mi się), bo i tak będą zbyt wysokopoziomowe na takie testy. Coś podnego robi np material-ui do React'a, ze swoimi GridBlock, Box, etc.

Ale again, to jest tylko sugestia, z mózgu, nie poparta niczym. Tylko moim osądem.

TomRiddle napisał(a):

zdeklaratyzować go jeszcze bardziej
(...)
np CollapsibleDiv, albo DesktopContainer/MobileContainer, ButtonWideOnMobile, MarginNoSmallerThan, CssBaseLine, etc.

Takie podejście jest ostatnio niestety modne, ale jest to też totalne zaprzeczenie idei stojącej u podstaw CSS i powrót do inlinowego stylowania, tyle tylko, że nazwanego trochę inaczej.

Po to przed laty rugowano z HTML atrybuty typu: color, bcolor, colspan, żeby oddzielić warstwę treści od warstwy prezentacyjnej.

Testowanie wizualne w Cypress:
https://docs.cypress.io/guides/tooling/visual-testing.html#Functional-vs-visual-testing
https://docs.cypress.io/plugins/#visual-testing

W skrócie robisz akcję, potem screen (całej strony albo konkretnego elementu), zapisujesz sobie w repo albo na serwerze (a w repo link do niego) i przy kolejnym odpaleniu testu raz jeszcze porównujesz screen (z jakimś dopuszczalnym marginesem błędu).

Takie jeszcze zastrzeżenie mam, że taki automat do testowania powinien być w stanie, sprawdzić wygląd w: Firefoksie, Chromie, Operze i na telefonie (przynajmniej) w Chromie. Bo niby nie ma w tej kwestii już takiego sajgonu jak jeszcze 10 lat temu, ale zawsze jakaś niespodzianka może wyskoczyć.

Freja Draco napisał(a):

Takie jeszcze zastrzeżenie mam, że taki automat do testowania powinien być w stanie, sprawdzić wygląd w: Firefoksie, Chromie, Operze i na telefonie (przynajmniej) w Chromie. Bo niby nie ma w tej kwestii już takiego sajgonu jak jeszcze 10 lat temu, ale zawsze jakaś niespodzianka może wyskoczyć.

Dużo zależy od aplikacji i jej użytkowników, nie zawsze jest sens się w to bawić - zazwyczaj wystarczy 1 najpopularniejszy browser/os użytkowników, ale gdyby ktoś chciał sprawdzać wszystko to też już istnieją rozwiązania np. https://www.browserstack.com/docs/automate/cypress/browsers-and-os albo https://docs.percy.io/docs/cross-browser-visual-testing

Dzięki @Markuz - niby znalazłem tego cypress w google, ale nie dotarłem do tego miejsca dokumentacji.
Wygląda wystarczająco sensownie, żeby sprawdzić i dać temu szansę.

Z jednej strony testowanie CSS to coś o czym nawet nie myślałem a sam pomysł na pierwszy rzut oka wydaje się dość potrzebny. Przy czym takie testowanie jest trochę bez sensu patrząc na to, że użytkownicy mogą mieć różne przeglądarki i różne rozdzielczości. W pewnym sensie nie sposób pisać testy na case każdego przesunięcia piksela. Ciężko to o edge casy kiedy wiele elementów może mieć position absolute i pozamiatane.
Nie wyborażam sobie żeby ludzi pisali testy do obrazków w Photoshopie, a od tego już bliska droga do layoutu strony.
Swoją drogą są te środowiska do testowania e2e przez realne symulowanie przeglądarki. Tyle że często nie radzą sobie z czekaniem, animacjami itd.
Mam wrażenie że w branży problem testów layoutu już istnieje od dawna ale nikt nie znalazł rozwiązania jak to robić łatwo i tak żeby dobrze działało. Być może ten problem jest tak trudny lub tak nieistotny, że uzysk z takiego narzędzia byłby niewspółmierny do pracy/kosztu stworzenia.

Możliwe że AET to coś czego szukasz, aety robią screeny na każdej stronie i jeżeli coś się rozjeżdża to wskazują dokładnie co jest nie tak z użyciem screenów. Na różnych rozdzielczościach

Link: https://github.com/Cognifide/aet