Błąd bazy danych WordPressa: [Illegal argument to a regular expression.]
SELECT DISTINCT SQL_CALC_FOUND_ROWS wp_users.ID,wp_users.display_name,wp_users.user_login FROM wp_users INNER JOIN wp_usermeta ON ( wp_users.ID = wp_usermeta.user_id ) WHERE 1=1 AND ( ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) OR ( wp_usermeta.meta_key = 'first_name' AND wp_usermeta.meta_value RLIKE '^aetest($|\\s)' ) ) OR (wp_users.ID LIKE '' OR wp_users.ID RLIKE '') OR (wp_users.user_email LIKE '' OR wp_users.user_email RLIKE '') OR (wp_users.user_url LIKE '' OR wp_users.user_url RLIKE '') OR (wp_users.display_name LIKE '' OR wp_users.display_name RLIKE '') OR (wp_users.user_login LIKE '' OR wp_users.user_login RLIKE '') OR (wp_users.user_nicename LIKE '' OR wp_users.user_nicename RLIKE '') OR (wp_usermeta.meta_key = 'nickname' AND (wp_usermeta.meta_value LIKE '' OR wp_usermeta.meta_value RLIKE '')) OR (wp_usermeta.meta_key = 'first_name' AND (wp_usermeta.meta_value LIKE '' OR wp_usermeta.meta_value RLIKE '')) OR (wp_usermeta.meta_key = 'last_name' AND (wp_usermeta.meta_value LIKE '' OR wp_usermeta.meta_value RLIKE '')) ORDER BY user_registered ASC LIMIT 0, 10

W tym wpisie przyjrzymy się, jak wygląda struktura testów (Testcase) funkcjonalnych kodowanych za pomocą pyATS. Struktura ta pozwala na łatwe i przejrzyste tworzenie testów, zarządzanie nimi oraz raportowanie wyników. Dzięki modularnej budowie, można łatwo rozbudowywać i dostosowywać testy do konkretnych potrzeb. Posłużymy się poniższym szablonem testcase: 

from pyats import aetest 

class MyTestcase(aetest.Testcase): 

    @aetest.setup 

    def setup(self): 

        # Kod do przygotowania środowiska testowego 

        pass 

    @aetest.test 

    def test1(self): 

        # Pierwszy test 

        assert True 

    @aetest.test 

    def test2(self): 

        # Drugi test 

        assert False, „Ten test celowo zawodzi” 

    @aetest.cleanup 

    def cleanup(self): 

        # Kod do sprzątania po testach 

        pass 

if __name__ == „__main__”: 

Na początku pliku importowane są niezbędne biblioteki. Podstawowy import to aetest z pakietu pyats, który zawiera klasy i dekoratory potrzebne do definicji i wykonania testów. Można również importować inne moduły Pythona, które są potrzebne do logiki testów, na przykład moduły do interakcji z urządzeniami sieciowymi, parserami danych czy bibliotekami asercji. Kluczowym elementem pliku z testami jest klasa testowa, która dziedziczy po aetest.Testcase. Klasa ta służy jako kontener na różne etapy testu (setup, testy właściwe, cleanup). Klasy mogą zawierać atrybuty instancji, które przechowują dane konfiguracyjne lub stanowe, wykorzystywane w różnych etapach testu. 

Metoda setup ma kluczowe znaczenie dla przygotowania środowiska przed przystąpieniem do właściwych testów. Może to obejmować sprawdzenie dostępności urządzeń, konfigurację wstępną, czy nawet czyszczenie stanów z poprzednich testów. Użycie self.failed() może przerwać wykonanie testu, jeśli setup nie zakończy się powodzeniem. Metoda ta musi być oznaczona dekoratorem @aetest.setup i tylko jedna metoda może mieć przypisany taki dekorator. Metoda cleanup służy do sprzątania po wykonaniu testów. Jest to miejsce na kod, który przywraca środowisko do stanu początkowego, zamyka otwarte połączenia lub usuwa tymczasowe pliki i dane. Jest to szczególnie ważne w testach, które modyfikują stan systemu lub urządzeń. Oznaczamy ją dekoratorem @aetest.cleanup i, podobnie jak dla przy metodzie setup, tylko jedna metoda może być oznaczona tym dekoratorem. 

Testy właściwe definiuje się jako metody w klasie testowej, oznaczone dekoratorem @aetest.test. Można zdefiniować dowolną liczbę metod testowych, a AEtest wykona je w kolejności ich definiowania. W metodach testowych umieszcza się logikę testową oraz asercje sprawdzające warunki testowe. Każda metoda testowa, ozdobiona dekoratorem @aetest.test, reprezentuje indywidualny test. Możliwe jest użycie asercji do weryfikacji oczekiwanych wyników. Asercje mogą sprawdzać wartości zwracane przez urządzenia, pliki logów, itp. AEtest obsłuży wyjątki asercji jako niepowodzenie testu. 

W PyATS AEtest, CommonSetup i CommonCleanup są specjalnymi sekcjami używanymi do wykonania operacji przygotowawczych i zamykających, które mają zastosowanie do całego zestawu testów w obrębie danego modułu testowego. Te sekcje ułatwiają zarządzanie kodem, który musi być wykonany przed i po wszystkich testach, bez konieczności powtarzania tego samego kodu w każdym teście.  

CommonSetup to sekcja wykonywana przed wszystkimi testami (Testcase’ami) w module testowym. Służy do konfiguracji warunków wstępnych, które są wspólne dla wielu przypadków testowych. Na przykład, może to obejmować ustanowienie połączenia z urządzeniami testowymi, konfigurację urządzeń do stanu wymaganego dla testów lub ładowanie danych testowych. Odpowiednio, CommonCleanup jest sekcją wykonywaną po wszystkich testach, służącą do przywrócenia środowiska testowego do stanu pierwotnego, zamknięcia połączeń, usunięcia konfiguracji testowej z urządzeń itp. Jest to kluczowe dla zapewnienia, że środowisko testowe nie zostanie zakłócone przez pozostałości po testach, co mogłoby wpłynąć na kolejne serie testów. Definiuje się je w module testowym poprzez dziedziczenie z odpowiednich klas bazowych aetest.CommonSetup i aetest.CommonCleanup, analogicznie do definiowania zwykłych przypadków testowych (Testcase): 

class MyCommonSetup(aetest.CommonSetup): 

    @aetest.subsection 

    def connect_to_devices(self, testbed): 

        # Logika połączenia z urządzeniami 

class MyCommonCleanup(aetest.CommonCleanup): 

    @aetest.subsection 

    def disconnect_from_devices(self): 

        # Logika rozłączenia z urządzeniami 

Oczywiście, w przypadku mniejszych testów, możemy cała tę logikę zawrzeć w blokach setup i cleanup każdego Testcase.