Powrót do: Podstawy Testów Automatycznych w Selenium i Python cz. 5 – Profesjonalna konfiguracja projektu
Wstęp do dziedziczenia w praktyce
W poprzednich sekcjach poznaliśmy wiele ciekawych i przydatnych koncepcji, które umożliwiły nam unikania duplikacji kodu np. poprzez dekoratory. Teraz poprawę naszych testów umożliwi poznany mechanizm dziedziczenia. Już trochę poznaliśmy praktyczne zastosowanie dziedziczenia przy okazji tworzenia klasy nasłuchującej zdarzenia ScreenshotListener(AbstractEventListener). Teraz jednak zrobimy dużo większe zmiany w naszym kodzie 😀
Wprowadźmy więc kolejne usprawnienia do tworzonego przez nas rozwiązania!
Przypomnijmy: to bardzo ważna sprawa aby dostrzegać zduplikowany kod. Już wiele razy wydzielaliśmy powtarzający się kod do niezależnych metod czy dekoratorów aby:
- po prostu przyspieszyć pisanie testów – nie trzeba nadmiarowo wypisywać identycznych linii,
- co ważniejsze, aby mieć pod kontrolą reużywany kod, aby łatwo go modyfikować – w jednym miejscu,
- wydzielać kod do osobnych plików, zmniejszając tym samym objętość plików z testami. Dzięki temu mamy krótsze i łatwiejsze do czytania testy…
Gdy się nad tym lepiej zastanowisz to ma sens 😉
Na przykład w kontekście specjalnej metody operational_helpers.visibility_of_element_wait – idealnie, że mamy ją w osobnym module operational_helpers. Gdy zmienialiśmy w niej driver na driver.wrapped_driver mogliśmy zaaplikować to łatwo w jednym miejscu. Wyobraź sobie, że nie mamy wydzielonej metody visibility_of_element_wait tylko wszędzie wrzucamy zwykły wait, bezpośrednio w naszych testach. Bylibyśmy zmuszeni wprowadzić zmianę np. związaną z wrapped_driver w każdym użyciu wait. Masa roboty, której uniknęliśmy!