Czy kod proceduralny testowania jednostkowego jest skuteczny?

13

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.

kanadyjski
źródło
13
Testowanie jednostkowe nie zapobiega nowym błędom, zapobiega regresjom.
Daenyth
2
możliwy duplikat Czy generatory testów jednostkowych pomogły Ci w pracy ze starszym kodem? i tuzin innych pytań. Szukaj „legacy unit test”
mattnz
4
Problem polega na tym, że kod to spaghetti / Big Ball Of Mud, a nie to, że ma on charakter „proceduralny” (dobry kod proceduralny jest w pełni sprawdzalny - BTDTGTTS). Twoje moce raczej wolą (więcej) testerów i zapewnią dogłębną profesjonalną kontrolę jakości w projekcie, jeśli naprawdę chcą „uniknąć ciągłej liczby błędów”.
komar
@ l0b0 tak zrobiłem. Przepraszam, zaktualizuję test, aby był jaśniejszy
kanadyjski
@mattnz Ya Szukałem testu jednostkowego, ale nie starszego. Zrozumiałem, że procedura! = Dziedzictwo, ponieważ wciąż powstaje nowy kod w tym formacie
canadiancreed

Odpowiedzi:

14

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ź.

Arseni Mourzenko
źródło
5

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.

Doktor Brown
źródło
5

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.

dietbuddha
źródło
4

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.

jmoreno
źródło
-4

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?

Rob Gray
źródło
5
-1: Problemem jest zły projekt i implementacja, a nie kod proceduralny. Tak jak potrafisz pisać okropne OP, możesz pisać świetny kod proceduralny.
mattnz
@mattnz - Nie jestem pewien, w jaki sposób twój komentarz odnosi się do tego, co powiedziałem o byciu lub niemożności testowania kodu procedury jednostkowej.
Rob Gray
7
Kod proceduralny nie równa się spaghetti. Bardzo możliwe jest pisanie w sposób proceduralny dobrze zaprojektowanego, modułowego, czysto oddzielonego kodu o wysokiej kohezji / niskim sprzężeniu.
Marjan Venema
2
Dobry projekt wprowadza testowanie jednostkowe w dowolnym kodzie, proceduralnym lub nie.
Doc Brown