Flagi funkcji PrestaShop 9.2: testowanie obu ścieżek Back Office
Flaga funkcji zmienia testowaną ścieżkę kodu. Dwaj testerzy mogą uruchamiać tę samą wersję PrestaShop, otwierać pozornie tę samą stronę Back Office, a mimo to testować różne implementacje. Bez wykazu flag ich wyniki mogą wyglądać na sprzeczne.
W zapowiedzi wersji 9.2 RC1 PrestaShop kieruje testerów do Parametry zaawansowane → Nowe i eksperymentalne funkcje. Na tej stronie sprawdź przełączniki dostępne w zainstalowanej wersji kandydującej. Według stanu na 26 września 2026 r. zawierające je wydanie nadal jest oprogramowaniem przedpremierowym. Oficjalne wskazówki RC1 dotyczące flag funkcji.
Ten artykuł dotyczy obsługi i testowania flag. Towarzyszący artykuł o migracji do Symfony omawia kod rozszerzeń stojący za przeniesionymi stronami.
Gdy przełącznik wybiera przeniesioną stronę administracyjną, uwzględnij kontrole migracji do Symfony dla programistów modułów, aby test odpowiadał rzeczywistemu kontraktowi rozszerzenia.
Odróżniaj dostępność, dojrzałość i aktywację
Trzy oddzielne pytania często sprowadza się do „Czy funkcja jest gotowa?”. Czy implementacja jest obecna w tym pakiecie? Jaką dojrzałość przypisuje jej projekt? Czy jest włączona w tej instalacji?
Funkcja oznaczona jako stabilna w systemie flag nadal może być dostarczana w wersji kandydującej. Eksperymentalna możliwość może pozostawać opcjonalna nawet po ustabilizowaniu wydania rdzenia. Zainstalowany moduł może również udostępniać zachowanie zależne od własnej konfiguracji.
W zapisie testu zachowaj wszystkie trzy informacje. „Przetestowano Kraje” jest niepełne, jeśli stara i przeniesiona ścieżka mogą współistnieć. „Przetestowano z włączoną przeniesioną ścieżką Krajów w tej kompilacji kandydującej” określa środowisko w znaczący sposób.
Nie wnioskuj o stanie flagi ze zrzutu ekranu. Strona może wyglądać podobnie po migracji. Odczytaj konfigurację i, gdy to właściwe, sprawdź aktywną ścieżkę lub implementację za pomocą obsługiwanej diagnostyki zainstalowanej aplikacji.
Podobnie nie zakładaj, że wyłączenie funkcji cofnie zmiany danych wykonane podczas jej działania. Przełącznik wybiera zachowanie; nie jest automatycznie wycofaniem transakcji ani obniżeniem wersji bazy danych.
Wiedz, które ścieżki ma objąć test
Uwagi dla programistów wersji 9.2 wskazują następujące przełączniki przeniesionych stron:
| Strona | Udokumentowana flaga |
|---|---|
| Kraje | country |
| Zwroty towarów | merchandise_return |
| Podłącz moduł do hooka | hook_module_v2 |
| Szybki dostęp | quick_access |
| Tłumaczenia treści e-maili | email_body_translation |
| Reguły podatkowe | tax_rules_group |
Te nazwy pochodzą z dokumentacji właściwej dla wersji, której akapit o statusie wydania nadal zawiera starsze sformułowanie dotyczące bety. Status wydania sprawdzaj w nowszej zapowiedzi RC, a przełączniki w dokładnie tej zainstalowanej kompilacji. Dokumentacja flag wersji 9.2.
Tabela nie obiecuje, że każda flaga pozostanie bezterminowo. Flagę można wycofać, gdy ścieżka stanie się standardową implementacją. Nie koduj na stałe trwałej polityki wsparcia zależnej od nieprzerwanej dostępności starego przełącznika.
Dla każdej strony dostosowanej przez zespół ustal, czy musisz testować bieżącą ścieżkę, alternatywną czy obie. Testowanie nieistotnych przełączników dodaje szumu. Pominięcie przełącznika sterującego dostosowaną stroną pozostawia rzeczywistą lukę w pokryciu.
Zapisz stan bazowy przed zmianami
Zapisz wersje rdzenia, modułów i motywu, bieżący kontekst sklepu oraz pełny zbiór stanów istotnych flag. Przed operacjami mogącymi zmienić trwałe dane wykonaj odtwarzalną migawkę testową.
Używaj małego zestawu testowego zaprojektowanego wokół celu strony. Dla Krajów może to być syntetyczny wpis konfiguracyjny i zależne od niego zachowanie sklepu. Dla Szybkiego dostępu może to być testowy link i pracownik z ograniczonymi uprawnieniami. Zestaw powinien uwidaczniać oczekiwany wynik.
Zmień jeden istotny przełącznik, a następnie powtórz tę samą operację biznesową. W miarę możliwości utrzymuj pozostałe zmienne bez zmian. Jeśli jednocześnie włączysz kilka możliwości, zaktualizujesz moduły i zmienisz uprawnienia, nie da się już jasno przypisać awarii.
Notatka o stanie bazowym powinna również opisywać stan sesji. Otwarte karty i zasoby w pamięci podręcznej mogą nie reprezentować nowo wybranej ścieżki. Zacznij porównanie od nowej nawigacji i potwierdź aktywną implementację przed zbieraniem dowodów.
Nie polegaj na pamięci w kwestii pierwotnego ustawienia. To wykaz pozwoli innemu testerowi później odtworzyć porównanie.
Porównuj zachowanie biznesowe obu ścieżek
Dla formularza administracyjnego testuj początkowe załadowanie, błąd walidacji, udany zapis i ponowne załadowanie. Dla siatki testuj właściwą listę, filtry i działania wierszy. Dla nawigacji testuj link i uprawnienia pracownika, który go otwiera.
Pożądana asercja to zwykle niezmiennik biznesowy: to samo zamierzone ustawienie zapisuje się w tym samym zakresie lub ta sama autoryzowana operacja wpływa na ten sam rekord. Identyczność pikseli nie musi być celem migracji.
Uwzględnij przypadek negatywny. Pracownik bez prawa zapisu nie powinien uzyskać go na alternatywnej ścieżce. Nieprawidłowa wartość nie powinna stać się akceptowana tylko dlatego, że zmienił się mechanizm renderowania formularza. Zapis dla konkretnego sklepu nie powinien rozszerzyć się na wszystkie sklepy.
Używaj zapisu porównawczego:
| Przypadek | Ścieżka bazowa | Ścieżka po migracji | Decyzja |
|---|---|---|---|
| Zapis prawidłowych danych testowych | Zapisany wynik | Zapisany wynik | Równoważność lub wyjaśniona różnica |
| Odrzucenie nieprawidłowych danych testowych | Zachowanie walidacji | Zachowanie walidacji | Brak niezamierzonego utrwalenia |
| Pracownik z ograniczeniami | Dozwolone operacje | Dozwolone operacje | Zachowana granica uprawnień |
| Ponowne załadowanie po zapisie | Wyświetlana wartość i zakres | Wyświetlana wartość i zakres | Potwierdzone utrwalenie |
Różnica może być zamierzona. Zapisz, dlaczego jest akceptowalna, zamiast zmuszać nową stronę do naśladowania starego błędu lub nieudokumentowanego dostosowania.
Traktuj powrót do starej ścieżki jako osobny eksperyment
Częstym błędem jest założenie, że jeśli nowa ścieżka zawiedzie, wyłączenie jej flagi całkowicie przywraca stare środowisko. Stara ścieżka może znów stać się aktywna, ale rekordy edytowane podczas eksperymentu mogą pozostać zmienione.
Po przetestowaniu nowej ścieżki przełącz z powrotem wyłącznie przez obsługiwany interfejs i sprawdź ten sam zestaw testowy. Potwierdź, że stara ścieżka potrafi odczytać wynikowy stan. Jeśli dokumentacja wersji kandydującej ostrzega przed nieodwracalnymi lub zmieniającymi się strukturami danych, zresetuj jednorazowe środowisko zamiast zakładać odwracalność.
Nie usuwaj wierszy bazy danych ani nie zmieniaj ręcznie magazynu flag, by wymusić przełącznik, którego aplikacja już nie udostępnia. Może to utworzyć niewspierany stan hybrydowy i sprawić, że późniejsze awarie będą mylące.
Gdy moduł dostosowuje się do obu ścieżek, sprawdź, czy nie stosuje tego samego skutku biznesowego dwukrotnie. Warstwa zgodności rejestrująca jednocześnie stare i nowe integracje może wymagać starannej logiki kierowania. Sama flaga nie dowodzi, że moduł poprawnie wybrał jedną ścieżkę.
Planuj wycofywanie flag
Strategia wsparcia oparta na „powiedz klientom, by wyłączyli nową stronę” może być tymczasowym obejściem, lecz nie trwałym planem implementacji. Jeśli stara ścieżka później zniknie, obejście zniknie razem z nią.
Śledź, które dostosowania nadal zależą od starej ścieżki i jakie dowody są potrzebne do usunięcia tej zależności. Uwzględnij odpowiedzialny moduł lub agencję i właściwą operację biznesową.
Gdy flaga zostanie usunięta w późniejszej wersji, zaktualizuj nazwy testów i dokumentację. Test deklarujący sprawdzanie wyłączonej starej ścieżki, gdy przełącznik już nie istnieje, tworzy fałszywe poczucie pewności. Preferuj nazwy przypadków skupione na zachowaniu, a ścieżkę implementacji zapisuj jako metadane środowiska.
Zespoły wsparcia powinny zachowywać wykaz flag przy każdym incydencie. Wczesne zapytanie o niego może wyjaśnić, dlaczego problem odtwarza się w jednym sklepie, a w innym nie, bez obwiniania losowego buforowania lub ponownej instalacji modułów.
Obsłuż przerwany eksperyment z flagą
Załóżmy, że tester włącza przeniesioną stronę, edytuje dane testowe i zostaje przerwany przed zapisaniem wyniku. Inny tester nie powinien wywodzić aktywnego stanu z niedokończonego raportu. Sprawdź przełącznik, otwórz ponownie dane testowe i porównaj je z zapisaną bazą przed kontynuacją.
Używaj zapisu eksperymentu z trzema jawnymi etapami: przygotowany, wykonany i przejrzany. Przygotowany oznacza udokumentowany stan początkowy. Wykonany oznacza zapisane działania i obserwacje. Przejrzany oznacza zinterpretowany wynik i znany końcowy stan środowiska.
To lekka praktyka koordynacyjna, nie nowa funkcja PrestaShop. Jest szczególnie przydatna, gdy kilka osób współdzieli instalację testową, a przełączniki funkcji wpływają na więcej niż jedną sesję testową.
Unikaj równoległych porównań ścieżek na tym samym współdzielonym zestawie testowym. Jedna osoba zmieniająca flagę lub konfigurację nadrzędną może unieważnić wynik drugiej. Jeśli to możliwe, używaj osobnych jednorazowych instancji do niezależnych eksperymentów albo rezerwuj środowisko na odpowiednie okno testowe.
Po zakończeniu eksperymentu stwierdź, czy środowisko przywrócono, zachowano do odtworzenia błędu czy wycofano. Zachowany stan awarii może być przydatnym dowodem, ale należy go oznaczyć, aby kolejny tester nie pomylił go ze zwykłą bazą.
Te zapisy zmieniają zmianę flagi w powtarzalny eksperyment. Pozwalają również odróżnić przerwane badanie od usterki wersji kandydującej, gdy późniejsza sesja napotka nieoczekiwaną stronę.
Przełącznik powinien dostarczać wiedzy
Celem oceny flagi wersji kandydującej jest ustalenie, czy konkretna ścieżka obsługuje konkretną operację. Zakończ każdy eksperyment, dokumentując aktywny stan, wynik i wszelkie wynikowe zmiany danych.
Jeśli ścieżka zawiedzie, zachowaj minimalny odtwarzalny przypadek. Jeśli przejdzie test, określ sprawdzony zakres zamiast deklarować uniwersalną gotowość. Jeśli nigdy jej nie sprawdzono, jawnie pozostaw ją jako nieprzetestowaną.
Flagi funkcji umożliwiają stopniową migrację, ale sprawiają też, że same numery wersji opisują mniej. Zdyscyplinowany wykaz i porównanie obu ścieżek zamieniają dodatkowe stany w użyteczne dowody zamiast ukrytej niepewności.
Kontekst platformy bazowej znajdziesz w naszym przewodniku po tworzeniu modułów PrestaShop 9; zastosuj powyższe kontrole właściwe dla wersji do ocenianej instalacji.