Marcin Stanek
2020-03-26 06:52

Cypress i wizualna regresja w testach funkcjonalnych. Opisałem to doskonałe połączenie w dzisiejszym poście. Pokazuję jak zaimplementować ten typ testów przy pomocy darmowego narzędzia cypress-image-snapshot.

https://marcinstanek.pl/cypress-7.html

#testowanieoprogramowania #testowanie #programowanie #programista15k #selenium #cypress #automatyzacja

Marcin Stanek

Ooo. No są właśnie na tych screenach wyniki jakie produkuje narzędzie ale widocznie dobilem do limitu dobowego w Firebase. :D Jutro screny się wyświetla. ;)

WeiXiao

to może imgur.com :D

Marcin Stanek
2020-03-19 14:23

https://marcinstanek.pl/playwright-1.html

Long story short, Playwright. Niedawno Microsoft ogłosił, że pracuję nad nowym narzędziem, którego będziemy mogli użyć między innymi do automatyzacji testów e2e. Pracują nad nim osoby odpowiedzialne za narzędzie Puppeter. Brzmi obiecująco? Super, nie jest to jeszcze gotowe w wersji 1.0 także zmiany będą na pewno - postanowiłem jednak sprawdzić jak działa, napisałem pierwsze testy, a wrażenia znajdziesz na moim blogu.

#testowanieoprogramowania #testowanie #programowanie #programista15k #selenium #cypress #automatyzacja

Marcin Stanek

Ciężko mi jednogłośnie odpowiedzieć po paru linijkach kodu. Niemniej, z Selenium mam dużo doświadczenia i jestem pewny że w conajmniej dwóch miejscach trzebaby było dodać wait na własną rękę. Tutaj otrzymujesz to out of the box. Co do niezawodności, testy były spójne nie było random faili podczas developmentu - trzeba jednak pamiętać że w dalszym ciągu to najprostsze testy. Moim zdaniem warto zrobić Proof of Concept jeżeli narzędzie spełnia Twoje wymagania.

rafal__

"Niedawno Microsoft ogłosił, że pracuję nad nowym narzędziem" - wow, gratuluję, nie wiedziałem, że Microsoft ogłasza nad czym pracujesz. // sorry, musiałem. #grammarnazi. Wiem, że pewnie automatyczna korekta, ale ostatnio to powszechny błąd, wszędzie widoczny ;)

Silv
2019-10-03 23:22

Kilka dni wcześniej pisałem na naszym mikroblogu o moich początkach w GNU Screen (tutaj). Do dziś nauczyłem się paru podstawowych poleceń. Dziś dalej będzie o GNU Screen-ie.

Uznałem w międzyczasie, że dobrze jest iść w stronę automatyzacji na Linuksie (a w zasadzie dawno temu, ale nie było okazji próbować). dlatego też teraz próbuję dalej.

Dla porządku: dokumentacja narzędzia GNU Screen jest dostępna pod adresem: https://www.gnu.org/software/screen/manual/screen.html. Zauważyłem jednak, że ktoś pisał w internecie, że nie wszystko w niej jest. Dlatego też, gdyby nie było czegoś, co według Was powinno być, polecam również zawsze próbować w man screen, lub online: https://linux.die.net/man/1/screen W swoich wpisach odnosić się będę zapewne najczęściej do wersji dokumentacji ze strony GNU, ponieważ tam są kotwice do poszczególnych sekcji.

Rekapitulacja wrażeń z używania GNU Screen-a

Komentując własne początki:

  1. Włączanie Screen-a. Całkiem wygodne jest włączanie za pomocą screen. Jedno polecenie – czego więcej potrzeba do szczęścia? Chyba tylko automatycznego uruchamiania z systemem. ;)
  2. Wyłączanie Screen-a. Całkiem wygodne jest wyłączanie: albo można wyłączać poszczególne okna (nawet za pomocą exit), albo wyłączyć całego Screen-a za pomocą CTRL+a, \, y. To y to odpowiedź na pytanie Screen-a, czy na pewno chcę wszystkie okna zamknąć. Teoretycznie (bardzo teoretycznie!) mogłoby być krócej – bez pytania. Ale akurat dodatkowe pytanie jest w tym przypadku, w moim odczuciu, bardzo sensowne. Wolę, jak mnie program zapyta, a nadto poprosi o naciśnięcie drugiego klawisza, dość daleko od poprzedniego. Gdyby klawisz był bliżej, mógłbym wyłączyć sobie przypadkowo całą pracę, naciskając inny przez pomyłkę. Gdyby zaś w ogóle nie było pytania, to najbardziej prawdopodobna pomyłka mogłaby być naciskając CTRL+a, a potem \ zamiast ]; klawisz \ zamknie mi sesję Screen-a ze wszystkimi oknami, zaś klawisz ] – wklei skopiowany tekst. — Jeszcze co do zamykania: nie jestem pewien, jak z uruchomionymi procesami i/lub aplikacjami. Dokumentacja mówi (tutaj), że proces, który jest w zamykanym oknie, otrzymuje tzw. "HANGUP condition" – ale nie wiem (jeszcze), co to znaczy.
  3. Przełączanie się między regionami. Jak się ma 2 lub 3 regiony, wygodnie mi przełączać się między nimi za pomocą CTRL+a, TAB; przy większej liczbie wydaje się, że wygoda spada.

Dalsza automatyzacja GNU Screen-a

Ale to jeszcze za mało automatyzacji dla mnie. Toteż wziąłem się za plik .screenrc.

Ogólnie, jak zauważyłem, Screen posiada 4 "rodzaje możliwości konfiguracji":

  1. za pomocą skrótów klawiszowych bezpośrednio w edytorze;
  2. za pomocą skrótu CTRL+a, a następnie wpisania dwukropka, a następnie nazwy opcji;
  3. za pomocą argumentów wywołania programu;
  4. za pomocą opcji właśnie w pliku .screenrc.

Opcje i argumenty między tymi czterema możliwościami nie odpowiadają sobie 1:1. W celu sprawdzenia, które opcje i argumenty są gdzie możliwe, poszukajcie w dokumentacji. Co do nazewnictwa: ja tutaj nazywam opcje "opcjami", ale w dokumentacji Screen-a używany jest zarówno termin "command", jak i termin "option"; nie wiem, jakie jest między nimi tam rozróżnienie; termin "option" występuje w niej 107 razy, a termin "command" – 720.

Poza automatyzacją korzyścią z używania pliku .screenrc jest "kopia zapasowa" poleceń ("kopia zapasowa" w stosunku do tego, co ma się we własnej pamięci). Czyli, po prostu, zapis z głowy na pamięć nieulotną. ;)

Plik .screenrc należy do rodziny plików konfiguracyjnych, wraz z plikami takimi jak .bashrc czy .vimrc, które zawierają startową konfigurację narzędzi, do których się odnoszą. Czyli jego zawartość jest odczytywana w czasie każdego uruchomienia Screen-a. (Nie wiem, czy można zmienić w Screen-ie, jaki plik jest odczytywany).

Side note: dlaczego wspólną częścią nazwy wszystkich wymienionych wyżej plików jest rc? Jest to skrót rozwijany m.in. jako "run commands", co mi wydaje się najbardziej prawdopodobne; niektórzy w internecie podają, że mógłby oznaczać inne rzeczy, np. runtime configuration. Szczegóły: (1) artykuł na Wikipedii o "run commands", (2) artykuł na Wikipedii o plikach konfiguracyjnych, (3) ten wątek na bbs.archlinux.org, (4) ten wątek na Stack Overflow.

Jeśli chodzi o zawartość pliku .screenrc, instrukcja podaje wiele opcji, które można w nim umieścić.

Ciekawą jest możliwość przemapowania dowolnego skrótu w Screen-ie, przynajmniej tak jest napisane w instrukcji. Toteż tak mi wpadło do głowy, że dość dobre będzie zmapowanie w tym pliku jakichś klawiszy na przemieszczanie "focusa" między regionami. Jednak teraz, po przetestowaniu, wydaje mi się, że nie jest to dla mnie zbyt wygodne; być może mam zbyt mocno zakorzenione w lewej ręce, że do przełączania okien/itp. to ALT+TAB, ALT+~ lub CTRL+ESC (skrót zależy od środowiska, w którym działam). Toteż wybrałem (na razie) CTRL+a, TAB.

Inną ciekawą rzeczą jest możliwość ustawienia własnej liczby linii, które będą przechowywane w buforze scrollback. Służy do tego opcja defscrollback. UPDATE: Domyślnie jest to 100 linii.

Jeszcze inną ciekawą rzeczą jest możliwość ustawienia layoutu Screena, czyli tego, ile jest tworzonych regionów i jak one są ułożone, i co w nich ma być uruchomione. Służą do tego m.in. opcje: screen, focus oraz split. Do zapisu bieżącego layoutu do pliku służy opcja layout dump.


Hm... a miałem tylko kilka zdań napisać...


Zauważyłem przed chwilą ciekawy bug/nie-bug w Screenie: gdy w jednym z dwóch regionów, które są ułożone poziomo, uruchamiam polecenie man {cośtam}, nie pokazuje mi wyjścia tego polecenia od samej góry, tylko zjeżdża kilka linii w dół. Strzałka w górę ani klawisz home nie działają. Muszę zjechać kilka linii w dół i dopiero wtedy działają i mogę przeczytać to, co jest na samej górze.


#właśnie-poznałem #oprogramowanie #linux #terminal #gnu-screen #automatyzacja