Zlokalizowanie elementu, oczekiwanie na możliwość interakcji, wykonanie akcji i weryfikacja wyniku: każda akcja automatyzacji składa się z tych czterech kroków. Zrozumienie selektorów, dynamicznego ładowania, iframe i shadow DOM pomaga tworzyć trwalsze skrypty.
Automatyzację WWW często rozumie się jako program, który klika przyciski za użytkownika. Kiedy jednak zaczyna się ją naprawdę tworzyć, okazuje się, że jedna akcja składa się z czterech kroków, a błąd w dowolnym z nich może wyglądać tak, jakby nic się nie wydarzyło.
Najpierw warto rozróżnić dwa pojęcia, które łatwo pomylić. Automatyzacja WWW ma szerszy zakres: obejmuje wykonywanie przez program czynności, które normalnie człowiek robiłby na stronie, w tym bezpośrednie pobieranie danych przez requesty. Automatyzacja przeglądarki jest bardziej konkretną gałęzią: program steruje prawdziwą przeglądarką, otwiera strony, wykonuje JavaScript i symuluje kliknięcia oraz wpisywanie. Gdy treść jest mocno dynamiczna lub interakcje są złożone, zwykle potrzebne jest właśnie to drugie podejście.
Cztery kroki jednej akcji
- Zlokalizuj element: Wskaż cel za pomocą id, name, class, selektora CSS albo XPath. Najpierw używaj semantycznych atrybutów, a do struktury lub indeksu sięgaj dopiero w razie konieczności.
- Poczekaj na możliwość interakcji: Samo pojawienie się elementu w DOM nie oznacza, że można go kliknąć. Poczekaj, aż będzie widoczny lub klikalny albo aż wróci konkretne żądanie. Czekaj na warunek, a nie na określoną liczbę sekund.
- Wykonaj akcję: Kliknij, wpisz lub przewiń. Własne komponenty często wymagają odtworzenia kolejności działań człowieka: najpierw otwarcie, potem oczekiwanie na wyrenderowanie listy, a następnie wybór według tekstu.
- Zweryfikuj wynik: Po akcji sprawdź, czy rezultat jest prawidłowy. Zobacz, czy zmienił się link, tekst strony albo co zwróciło API. Bez tego kroku niepowodzenie może zostać uznane za sukces, a późniejsze ponowienia i alerty nie będą miały wiarygodnej podstawy.
Spośród czterech kroków najwięcej czasu na debugowanie zwykle zajmują drugi i czwarty. Nie dlatego, że są trudne, lecz dlatego, że często nie wywołują błędu i po cichu dają nieprawidłowy wynik.
Stabilność selektora decyduje o trwałości skryptu
Gdy strona się zmienia, zakodowany na sztywno locator może przestać działać. Lokalizowanie po tekście, położeniu lub indeksie jest najmniej odporne na zmiany: dodanie jednego przycisku albo zmiana jednego komunikatu może zaburzyć wszystko.
Jeśli można, używaj id, name lub atrybutów data. Gdy potrzebne są locatory strukturalne, trzymaj je w jednym miejscu, aby przy zmianie poprawiać jeden fragment zamiast dziesiątek linii. Nie zakładaj też, że po napisaniu skrypt nie będzie wymagał opieki; aktualizacje stron są normalne, a duża część kosztu utrzymania skupia się właśnie tutaj.
Dynamiczne ładowanie: ważniejsze jest, na co czekasz, niż jak długo
Dziś niewiele stron ma wszystko gotowe od razu po zakończeniu początkowego ładowania. Dane są renderowane przez asynchroniczne żądania, więc elementy pojawiają się później, niż można oczekiwać.
Stałe opóźnienia są powszechne, ale też łatwo zawodzą: 3 sekundy uśpienia mogą nie wystarczyć na wolnej maszynie, a na szybkiej tylko marnują czas. Właściwe podejście polega na czekaniu na spełnienie warunku i działaniu dopiero wtedy, gdy element naprawdę jest klikalny.
Jeśli nie można znaleźć elementu, najpierw sprawdź iframe i shadow DOM
Gdy element wyraźnie widać na stronie, ale skrypt nie może go znaleźć, problem często leży nie w selektorze, lecz w zakresie.
iframe jest osobnym dokumentem. Najpierw trzeba przełączyć się do odpowiedniego frame, wyszukać element, a po operacji wrócić na zewnątrz; inaczej kolejne wyszukiwania będą wykonywane w złym kontekście. Węzłów wewnątrz shadow DOM nie można bezpośrednio trafić selektorem CSS z zewnątrz. Najpierw trzeba uzyskać shadow root, a potem szukać w jego wnętrzu. Obie sytuacje bywają mylone ze zmianą układu strony i prowadzą do niepotrzebnego debugowania.
Dwie kolejne rzeczy, o których łatwo zapomnieć
Pierwsza to sesja. W zadaniach wymagających logowania trzeba przemyśleć, jak zapisać i ponownie wykorzystać stan zalogowania. W przeciwnym razie przy każdym uruchomieniu konieczne będzie ponowne logowanie, które może jeszcze utknąć na etapie weryfikacji.
Druga to środowisko. Jeśli wszystkie zadania współdzielą jedno środowisko przeglądarki, sesje i cache mogą wzajemnie się zanieczyszczać. Zadania, które osobno działają poprawnie, po uruchomieniu razem mogą zacząć sobie przeszkadzać. Gdy z jednego zadania robi się kilka, wydzielenie osobnej warstwy izolacji środowisk oszczędza wiele problemów. Narzędzia takie jak PurpleMark zapewniają osobny fingerprint i osobny proxy dla każdego środowiska, a framework automatyzacji skupia się na wykonywaniu akcji.
Jedną granicę warto ustalić przed rozpoczęciem
Automatyzacja może zastąpić powtarzalne czynności, ale nie etapy wymagające udziału prawdziwej osoby. Jeśli docelowy proces obejmuje weryfikację twarzy w czasie rzeczywistym lub ręczną kontrolę, nie da się go zautomatyzować w 100%.
Dlatego najpierw sprawdź cały proces najprostszą metodą: przejdź go ręcznie od początku do końca, zapisz każdy krok i upewnij się, czy nie ma etapu niemożliwego do przejścia. Dopiero wtedy zdecyduj, ile pracy programistycznej warto zainwestować. Możliwość techniczna i zgodność z zasadami to także dwie różne sprawy, dlatego wcześniej sprawdź warunki korzystania z platformy docelowej.
