Czy powinny istnieć testy jednostkowe złożonych wyrażeń regularnych?

Czy powinienem pisać testy jednostkowe dla złożonych wyrażeń regularnych w mojej aplikacji?

• Z jednej strony: są łatwe do przetestowania, ponieważ format wejściowy i wyjściowy jest często prosty i dobrze zdefiniowany, i często mogą stać się tak złożone, więc ich testy są szczególnie cenne.
• Z drugiej strony: one same rzadko stanowią część interfejsu niektórych jednostek. Lepiej byłoby przetestować interfejs i zrobić to w sposób, który pośrednio testuje wyrażenia regularne.

EDYTOWAĆ:

Zgadzam się z doktorem Brownem, który w swoim komentarzu zauważa, że ​​jest to szczególny przypadek jednostkowych testów komponentów wewnętrznych .

Ale ponieważ wyrażenia regularne komponentów wewnętrznych mają kilka specjalnych cech:

1. Wyrażenie jednowierszowe może być naprawdę złożone, bez oddzielnego modułu.
2. Regeksy odwzorowują dane wejściowe na dane wyjściowe bez żadnych skutków ubocznych, a zatem są naprawdę łatwe do osobnego przetestowania.

Odkładając na bok dogmatyzm, prawdziwe pytanie brzmi, czy zapewnia ono wartość jednostkowym testom złożonych wyrażeń regularnych. Wydaje się całkiem jasne, że zapewnia wartość (niezależnie od tego, czy wyrażenie regularne jest częścią interfejsu publicznego), jeśli wyrażenie regularne jest wystarczająco złożone, ponieważ pozwala na znajdowanie i odtwarzanie błędów i zapobieganie regresjom.

Regex może być potężnym narzędziem, ale nie jest to narzędzie, któremu można zaufać, jeśli nadal będzie działać, jeśli wprowadzisz nawet niewielkie zmiany w złożonych wyrażeniach regularnych.

Stwórz więc wiele testów dokumentujących przypadki, które powinien obejmować. I stwórz wiele testów, które dokumentują przypadki, które powinny zakończyć się niepowodzeniem, jeśli zostaną użyte do weryfikacji.

Ilekroć potrzebujesz zmienić wyrażenia regularne, dodajesz nowe przypadki jako testy, modyfikujesz wyrażenia regularne i mam nadzieję na najlepsze.

Gdybym był w organizacji, która generalnie nie używałaby testów jednostkowych, nadal napisałbym program testowy, który przetestowałby każde wyrażenie regularne, którego byśmy użyli. Zrobiłbym to nawet w swoim własnym czasie, gdybym musiał, moje włosy nie muszą tracić więcej koloru.

Wyrażenia regularne są kodem wraz z resztą aplikacji. Powinieneś przetestować, czy kod ogólnie robi to, czego oczekujesz. Ma to kilka celów:

• Testy są dokumentacją wykonalną. Wyraźnie pokazuje, czego potrzebujesz do wykonania kodu. Jeśli jest testowany, jest to ważne.
• Przyszli opiekunowie mogą być pewni, że jeśli je zmodyfikują, testy zapewnią, że zachowanie się nie zmieni.

Ponieważ istnieje dodatkowa przeszkoda do pokonania, ponieważ kod w innym języku jest osadzony z resztą, najprawdopodobniej powinieneś poświęcić tę dodatkową uwagę na korzyść konserwacji.

Krótko mówiąc, powinieneś przetestować swoją aplikację, kropka. Niezależnie od tego, czy testujesz wyrażenie regularne za pomocą automatycznych testów, które uruchamiają go w oderwaniu, jako część większej czarnej skrzynki, czy też po prostu majstrujesz przy niej ręcznie, jest to kwestia dodatkowa, o której musisz upewnić się, że działa.

Główną zaletą testów jednostkowych jest oszczędność czasu. Pozwalają Ci przetestować tę rzecz tyle razy, ile chcesz teraz lub w dowolnym momencie w przyszłości. Jeśli istnieje jakikolwiek powód, aby sądzić, że wyrażenie regularne zostanie w dowolnym momencie poddane refaktoryzacji, poprawione, otrzyma więcej ograniczeń itp., To tak, prawdopodobnie potrzebujesz testów regresji, a kiedy to zmienisz, będziesz musiał przejść przez godzinę zastanowienia się nad wszystkimi przypadkami krawędzi, żebyś go nie złamał. To lub nauczysz się żyć ze strachem przed kodem i po prostu nigdy go nie zmieniaj.

Z drugiej strony: one same rzadko stanowią część interfejsu niektórych jednostek. Lepiej byłoby przetestować interfejs i zrobić to w sposób, który pośrednio testuje wyrażenia regularne.

Myślę, że sam na to odpowiedziałeś. Regeksy w jednostce są najprawdopodobniej szczegółem implementacji.

To, co jest potrzebne do testowania SQL, prawdopodobnie dotyczy także wyrażeń regularnych. Kiedy zmieniasz kawałek SQL, prawdopodobnie uruchamiasz go ręcznie przez jakiegoś klienta SQL, aby sprawdzić, czy daje to, czego oczekujesz. To samo dotyczy zmiany wyrażenia regularnego. Używam narzędzia wyrażenia regularnego z przykładowymi danymi wejściowymi, aby sprawdzić, czy robi to, czego oczekuję.

Przydaje mi się komentarz w pobliżu wyrażenia regularnego z próbką tekstu, który powinien pasować.

Jeśli musisz zapytać, odpowiedź brzmi tak.

Załóżmy, że pojawi się jakiś FNG i myśli, że może „poprawić” regex. Teraz jest FNG, więc automatycznie idiotą. Dokładnie taka osoba, która nigdy nie powinna dotykać twojego cennego kodu w żadnym wypadku! Ale może jest spokrewniony z PHB czy coś takiego, więc nic nie możesz zrobić.

Tyle że wiesz, że PHB pociągnie cię za kopanie i krzyczenie z powrotem do tego projektu, aby „może dać facetowi kilka wskazówek na temat tego, jak popełniłeś ten bałagan”, gdy wszystko pójdzie źle. Zapisujesz więc wszystkie przypadki, które dokładnie rozważyłeś , budując swoje piękne dzieło ekspresji.

A ponieważ spisałeś je wszystkie, masz dwie trzecie drogi do posiadania zestawu przypadków testowych, ponieważ - spójrzmy prawdzie w oczy - przypadki testowe wyrażeń regularnych są trudne do uruchomienia po zbudowaniu frameworka.

Teraz masz zestaw warunków brzegowych, alternatyw i oczekiwanych rezultatów. I nagle przypadki testowe stały się dokumentacją tak, jak obiecano we wszystkich tych postach na moim blogu Agile. Wskazujesz tylko FNG, że jeśli jego „poprawa” nie przejdzie istniejących przypadków testowych, to nie jest to duża poprawa, prawda? I gdzie są proponowane przez niego nowe przypadki testowe, które wykazują pewien problem z oryginalnym kodem, który ponieważ działa, nie musi być modyfikowany, nigdy !!!