Najlepsze praktyki testowania regresji na stronach WordPress?

Cześć wszystkim,

Chciałbym usłyszeć, co inni dostarczają klientom kompleksowe rozwiązania nieblogowe z WordPress jako platformą używaną do automatycznego testowania regresji ?

Dla tych, którzy nie są zaznajomieni z terminem „testowanie regresji” Wikipedia definiuje go jako:

Testowanie regresyjne to każdy rodzaj testowania oprogramowania, którego celem jest wykrycie błędów oprogramowania po wprowadzeniu zmian w programie (np. Poprawki błędów lub nowa funkcjonalność) poprzez ponowne przetestowanie programu. Celem testów regresji jest upewnienie się, że zmiana, taka jak poprawka błędu, nie wprowadziła nowych błędów.

Bardziej wymowne Wikipedia mówi, co jest dokładnie tym, czego obecnie doświadczam w projekcie:

Doświadczenie pokazuje, że gdy oprogramowanie jest naprawione, pojawienie się nowych i / lub ponowne pojawienie się starych usterek jest dość powszechne. Czasami pojawia się ponowny powrót, ponieważ poprawka gubi się w wyniku złych praktyk kontroli wersji (lub zwykłego błędu ludzkiego w kontroli wersji). Często naprawa problemu będzie „delikatna”, ponieważ rozwiązuje problem w wąskim przypadku, w którym po raz pierwszy go zaobserwowano, ale nie w bardziej ogólnych przypadkach, które mogą pojawić się w trakcie życia oprogramowania. Często naprawa problemu w jednym obszarze nieumyślnie powoduje błąd oprogramowania w innym obszarze. Wreszcie, często zdarza się, że gdy jakaś funkcja jest przeprojektowywana, niektóre z tych samych błędów, które popełniono w oryginalnej implementacji funkcji, zostały popełnione w przeprojektowaniu.

Biorąc pod uwagę globalny charakter akcji i filtrów, stwierdzam, że złożoność zaczyna rosnąć wraz z dodawaniem większej liczby żądanych przez klienta funkcji i trudno jest uzyskać stabilną złożoną wtyczkę, szczególnie jeśli używa ona wielu wywołań WP_Queryi często aktualizuje bazę danych .

Moim zdaniem rozwiązaniem byłoby skonfigurowanie testowania regresyjnego z serią „przypadków testowych” w celu utworzenia „zestawu testowego”. Z założenia nie jest to takie trudne, gdy testujesz wyjście HTML żądań HTTP GET. Ale staje się to trochę bardziej skomplikowane, gdy musisz przetestować rzeczy po zalogowaniu za pomocą konsoli administracyjnej i / lub przetestować interakcje jQuery.

Ustawiam to jako wiki społeczności, w nadziei, że możemy tutaj zebrać najlepsze praktyki, ale naprawdę chcę usłyszeć procesy, jeśli korzystają z nich inni specjaliści WordPress.

PHPUnit przyszedłby do głowy, gdyby pakiet testowy WP nie był tak zepsuty, a WP został zaprojektowany i napisany w sposób, który mógłby być właściwie przetestowany. ;-)

Mówiąc poważniej, możesz przetestować swoje wtyczki, ile chcesz z ich funkcjonalnego punktu widzenia za pomocą testów jednostkowych i tym podobnych. Problem polega na tym, że testy te nie zagwarantują, że złapią subtelne szanse wprowadzone przez aktualizacje WP, nie mówiąc już o tym, że będą kontynuować pracę po podłączeniu do niestandardowej instalacji WP.

Wśród kolorowych rzeczy, które widziałem, wydarzyły się:

• Subtelna zmiana w WP API wpływa na funkcjonalność wtyczki, np. Zaczep, którego używasz do uzyskania identyfikatora terminu, a teraz otrzymuje identyfikator taksonomii terminu. (Są duże szanse, że warunki testu dogodnie mają ten sam identyfikator dla obu).

• Subtelna zmiana w WP API skutkuje otrzymaniem WP_Errorobiektu zamiast wcześniej oczekiwanej wartości falsejako złych danych wejściowych.

• Twoja wtyczka jest dodawana z folderu mu-plugins, co powoduje nieznacznie inny przepływ kodu.

• Twoja wtyczka działała dobrze do momentu włączenia memcached lub innego trwałego sklepu.

• Twoja wtyczka działała dobrze, dopóki nie pogardzono switch_to_blog ().

• Wtyczka zmienia zaczep, na którym się znajduje, kiedy jest wywoływana, i nieświadomie przerywa ją jako efekt uboczny.

• Wtyczka (un?) Świadomie przesuwa dane wejściowe lub wyjściowe do momentu, w którym wszystko wygląda na zepsute, nawet jeśli nie jesteś winny.

Mógłbym ciągle rozszerzać listę, ale byłyby to kluczowe elementy, które złamały moje własne wtyczki. Te dwa elementy można prawdopodobnie złapać podczas testów jednostkowych. Kolejne dwa również, jeśli jesteś wystarczająco cierpliwy, ale argumentowałbym, że WP nie powinna zmieniać sposobu działania rzeczy, kiedy one wystąpią. Żadna ilość testów nie będzie działać w przypadku błędnej implementacji switch_to_blog (). A dwa ostatnie są beznadziejnie niestabilne.

Aha i ... nawet nie zaczynaj mnie od ataku załączników, automatycznych wersji roboczych, poprawek, pozycji menu i tego, co nie skończyło się w tabeli postów.

Powodzenia... :-)

Zdecydowanie powinieneś rozważyć Selen .

Umożliwia rejestrowanie działań (np. Wprowadzanie danych do formularza, klikanie łącza), a następnie wykonywanie twierdzeń. Integruje się również z PHPUnit. Bardzo polecam sprawdzenie dwuminutowej wersji demonstracyjnej.

Selen jest prawdopodobnie użyteczny, ale myślę, że w dzisiejszych czasach przekodowanie będzie lepsze i łatwiejsze w użyciu. W przypadku najprostszego testu regresji wizualnej ma nawet rozszerzenie, które wykonuje zrzuty ekranu i automatycznie je porównuje.

Oczywiście testy Codeception WebDriver mogą pójść dalej i przeprowadzić testy regresji funkcjonalnej . Możesz wypełniać i przesyłać formularze, klikać przyciski i linki w witrynie, wykonywać dowolne JS itp. Możesz używać w swoich testach prawdziwej przeglądarki, takiej jak Firefox lub Chrome, lub możesz przeprowadzać bezgłowe testy za pomocą PhantomJS . Oznacza to, że możesz nawet uruchomić testy WebDriver wtyczki w ramach procesu kompilacji na Travis CI, jeśli chcesz.

Istnieje nawet kilka bibliotek specyficznych dla WordPress, które pomogą Ci zacząć:

• Przeglądarka WP
• WP Codeception