Odnajdywanie wzorców awarii w teście jednostek

Question

Jestem nowy w testowaniu jednostek, a ja dopiero wchodzę w rutynę budowania zestawów testów. Mam dość duży projekt, od którego chcę budować testy.

Próbuję znaleźć ogólne strategie i wzorce do budowania zestawów testów. Kiedy patrzysz na lekcję, wiele testów przychodzi do ciebie oczywiście z powodu natury klasy. Powiedz o klasie "konto użytkownika" z podstawowymi operacjami CRUD, powiązanymi z tabelą bazy danych, będziemy chcieli przetestować - cóż, CRUD.

• tworzenia obiektu i sprawdzając, czy istnieje
• zapytania jego właściwości
• zmianę niektórych właściwości
• zmienić niektóre właściwości do błędnych wartości
• i usuń go ponownie.

chodzi o jak złamać rzeczy, istnieją „fail” testy wspólne dla większości klas CRUD jak:

• Nieprawidłowe typy danych wejściowych
• Szereg jako klucz ID, który przekracza zakres wybrany typ danych
• Wejście w błędnym kodowaniem znaków
• wejściowe, które jest zbyt długi

I tak dalej i tak dalej.

Dla zainteresowanych z operacjami na plikach testów jednostkowych, lista „rzeczy łamanie” może być

• Nieprawidłowe znaki w nazwie pliku
• Nazwa pliku zbyt długo
• Nazwa pliku używa błędnej protokołu lub ścieżki

Jestem prawie pewien, że podobne wzorce - stosowane poza testem jednostkowym, nad którym obecnie pracujemy - można znaleźć dla większości testowanych urządzeń.

Teraz moje pytanie brzmi:

• mam rację widząc takie "wzorce łamiącym"? Czy dostaję coś kompletnie błędnego w testowaniu Jednostki i jeśli zrobiłem to dobrze, to nie byłoby to wcale problemem? Czy testowanie jednostek to proces znalezienia jak największej liczby sposobów na rozbicie jednostki, jak to możliwe?

• Jeśli mam rację: czy istnieją już definicje, listy, arkusze do ściągnięcia takich wzorców?

• Czy są jakieś przepisy (głównie w PHPUnit, ponieważ to jest struktura, w której pracuję), aby zautomatyzować takie wzorce?

• Czy istnieje pomoc - w postaci list kontrolnych lub oprogramowania - aby pomóc w napisaniu pełnych testów?

Answer 1

Masz zasadniczo rację. Poszukiwanie sposobów, które mogłyby złamać twój kod, jest kluczową częścią i umiejętnością testowania jednostek. Jednak testowanie jednostkowe stosowane w TDD działa nieco inaczej. W TDD najpierw wypiszesz test na nowy element funkcjonalności, a następnie utworzysz kod, aby przejść test. Nacisk jest tutaj inny, mimo że efekt końcowy jest podobny.

W TDD, jedna "ciągle zmienia kapelusze" - trochę testów, trochę kodu. W tej metodzie testowanie nie jest częścią zautomatyzowaną, ale można niemal powiedzieć, że jest to klucz do procesu twórczego. Pisząc testy, projektujesz również interfejs swojej jednostki i myślisz z punktu widzenia jej (przyszłych) klientów - czego mogą się spodziewać i co mają zapewniać? Następnie zmieniasz kapelusze i wchodzisz do wnętrza urządzenia, aby spełnić te oczekiwania.

Nie sądzę, że można to zastąpić po prostu zaznaczeniem pozycji na liście. Oczywiście, gdy zabraknie pomysłów na przetestowanie rzeczywistej jednostki, nigdy nie boli sprawdzenie takiej listy. Jednak takie arkusze ze względu na swój charakter mogą zawierać jedynie uogólnienia, które mogą, ale nie muszą dotyczyć konkretnego projektu i określonej klasy do testowania. Ale najwyraźniej masz doświadczenie i nastawienie, aby znaleźć dobre przypadki testowe dla twoich konkretnych jednostek :-)