Czy kod proceduralny testowania jednostkowego jest skuteczny?

W obecnym projekcie moce, które chcą włączyć testy jednostkowe do naszego cyklu rozwoju, aby uniknąć stałej liczby błędów, które wydają się przenikać do naszego kodu. Problem polega na tym, że kod spaghetti jest w 95% procenty proceduralny, z którym nigdy nie przeprowadzałem testów jednostkowych (całe moje doświadczenie z testowaniem jednostkowym dotyczyło kodu OOP)

Więc w skrócie moim pytaniem jest, czy rozsądnie byłoby przejść do testów jednostkowych przy użyciu naszej obecnej bazy kodów, czy sugerować odłożenie go do momentu migracji aplikacji do odpowiedniego środowiska OOP?

PS: Podczas gdy próbowałem nadać temu pytaniu charakter niezależny od języka, wydaje mi się, że stwierdzenie, że dana aplikacja używa PHP i javascript, pomoże udzielić bardziej szczegółowych odpowiedzi, które mogłyby odpowiedzieć na to pytanie, ponieważ z doświadczenia wynika, że ​​takie zdarzenie występuje najczęściej w przypadku takich aplikacji.

Testowanie jednostkowe działa dobrze z obiektami, zwłaszcza że zapewnia wiele fantazyjnych funkcji, takich jak obiekty próbne, co pomaga szybciej tworzyć lepsze testy.

To powiedziawszy, nic nie zabrania przeprowadzania testów jednostkowych na proceduralnej bazie kodu . W OOP większość testów jednostkowych polega na testowaniu metod poprzez przekazanie im niektórych parametrów i oczekiwanie wyniku lub wyjątku określonego typu. Można to zrobić do tej pory również za pomocą kodu proceduralnego; po prostu zamiast metod testowania przetestujesz funkcje .

Pamiętaj, że będziesz musiał:

• Wyizoluj funkcje, które musisz przetestować, i te, których nie musisz. W OOP jest to łatwe: prywatne metody nie muszą być testowane, ponieważ dzwoniący nigdy nie będą mogli uzyskać do nich bezpośredniego dostępu. Możliwe, że w twoim kodzie proceduralnym niektóre funkcje są takie i nie wymagają testów.

• Pomyśl o zasięgu globalnym . Problem istnieje również w OOP, ale jeśli powiesz, że musisz przetestować kod spaghetti, istnieje prawdopodobieństwo, że ludzie, którzy napisali ten kod, mają złe nawyki, takie jak zbyt częste używanie zakresu globalnego i robienie szalonych rzeczy, takich jak zmiana $_GETlub $_POSTtablice wewnątrz Funkcje.

• Zajmuj się kodem poza funkcjami. Jest to bardziej skomplikowany przypadek, ale nadal możliwy. Albo require_oncestrona, aby zobaczyć, co się dzieje i złapać dane wyjściowe przez ob_start/ob_get_clean , albo wykonujesz żądanie HTTP z zestawu testów i analizujesz odpowiedź, analizując kod HTML. To nie jest tak naprawdę testowanie interfejsu użytkownika: tutaj nie obchodzi cię, czy przycisk na stronie pojawia się po lewej lub po prawej stronie, czy też link jest pisany dużymi czerwonymi dużymi literami lub małymi niebieskimi. Chodzi o to, aby znaleźć niektóre elementy HTML za pośrednictwem DOM i porównać ich zawartość z oczekiwanymi.

• Przetestuj kody odpowiedzi . require_oncebuforowanie danych wyjściowych jest dobre, ale musisz także sprawdzić, jak aplikacja internetowa radzi sobie z błędami. Na przykład jeśli oczekiwany wynik testu to 404 Nie znaleziono, musisz wykonać żądanie HTTP, aby wiedzieć, jaka jest odpowiedź.

zasugeruj, aby zostało ono odroczone do momentu migracji aplikacji do odpowiedniego środowiska OOP

Przygotuj kilka automatycznych testów przed migracją na inną platformę, a nie później. Dodaj kolejne testy podczas migracji, a nie później. Jeśli testy te są „testami integracyjnymi” lub testami jednostkowymi, musisz sam zdecydować, ale zazwyczaj możesz użyć swojej ulubionej struktury testowej xUnit dla obu rodzajów.

Najskuteczniejszym sposobem rozpoczęcia testów jednostkowych jest identyfikacja najczęściej występujących błędów lub ich najwyższych kosztów. Następnie utwórz testy ukierunkowane na te błędy.

Sposób wdrożenia tych testów różni się w zależności od paradygmatu i języka. Najważniejsze rzeczy, które wpłyną na twoją zdolność do przeprowadzania testów jednostkowych, to jakość kodu; mniej, więc zastosowany paradygmat. Pamiętaj, że testowanie jednostkowe polega na testowaniu „jednostki” kodu w izolacji. Wszystko, co wpływa na twoją zdolność do izolowania „jednostek” kodu, utrudni testowanie.

• wykorzystanie globali
• skutki uboczne
• ściśle powiązany kod
• źle połączony kod
• duża liczba warunków warunkowych
• źle zaprojektowane „jednostki”

Wszystko to będzie miało większy wpływ na trudność testowania niż paradygmat językowy.

W każdej sytuacji, w której możesz automatycznie testować części kodu, testowanie jednostkowe może być skuteczne. Zatem pytanie nie brzmi, czy kod proceduralny może być skutecznie testowany jednostkowo, pytanie brzmi: czy TEN kod może być testowany jednostkowo. Będzie to zależeć od tego, ile stanów czyta i ile ustawia. Idealnie, odpowiedź na oba pytania jest równa zero, ale jeśli nie, nadal możesz go przetestować.

Jak zawsze trzeba porównać pewność, że kod jest poprawny, z kosztem uzyskania tej pewności. Należy pamiętać, że część korzyści dla testów jednostkowych wyraźnie identyfikuje zależności iw tym sensie jeszcze bardziej efektywne jest testowanie jednostkowe kodu proceduralnego w porównaniu z kodem OOP.

Nie sądzę, aby możliwe było przeprowadzenie prawdziwych testów jednostkowych pod kątem kodu proceduralnego. Głównym problemem jest to, że każda procedura prawdopodobnie będzie miała wiele zależności, których nie można usunąć. W najlepszym wypadku testy będą testami integracyjnymi. Zrobiłem podobną rzecz wiele księżyców temu z modułami VB6 i modułami VBA w MS Access.

To powiedziawszy, jeśli możesz umieścić testowe rusztowanie wokół metod powodujących najwięcej bólu, to musi być wartościowe, prawda?