← Powrót do Bazy wiedzy← Poprzednie pytanieNastępne pytanie →
programowanieProgramista Perl, inżynier ds. testowania

Jak działa testowanie w Perl: jakie wbudowane i zewnętrzne moduły do testowania istnieją, czym się różnią i jakie praktyki testowania są powszechnie stosowane w projektach Perl?

Zdaj rozmowy kwalifikacyjne z asystentem AI Hintsage

Odpowiedź

W Perl tradycyjnie używa się pakietu modułów do testowania: Test::Simple, Test::More, a także kompleksowych frameworków jak Test::Class, Test::Most. Podstawowym jest Test::More — oferuje bogaty zestaw funkcji: sprawdzanie równości, porównywanie struktur, testowanie pod kątem wyjątków i inne.

Klasyfikacja popularnych modułów:

  • Test::Simple — do bardzo prostych, podstawowych testów;
  • Test::More — standard de facto dla większości projektów;
  • Test::Exception, Test::Deep, Test::Warn — do sprawdzania dodatkowych aspektów (wyjątki, zagnieżdżone struktury, ostrzeżenia);
  • Test::Class, Test::Class::Moose — podejścia obiektowe.

Przykład testu z Test::More:

use Test::More tests => 2;

is(2 + 2, 4, 'Suma działa');
like('foo_bar', qr/foo/, 'Jest foo');

Najlepsze praktyki:

  • Wszystkie publiczne moduły powinny mieć testy automatyczne w katalogu t/-.
  • Nie łączyć danych testowych z kodem produkcyjnym.
  • Stosować testy jednostkowe, integracyjne, czasami testy oparte na właściwościach.

Pytanie podchwytliwe

Czy można napisać własne testy w Perl bez używania modułów Test::*, po prostu używając konstrukcji die/print? Jakie są ryzyka związane z takim podejściem?

Odpowiedź: Formalnie tak — można pisać własne "testy", używając print i die do wyświetlania wyników. Jednak w takim przypadku nie tworzy się odpowiedniego podejścia do automatyzacji: brak wsparcia dla integracji TAP/CPAN, trudności w tworzeniu raportów i analizowaniu wielu testów, trudności w skalowaniu i wsparciu bazy testowej.

Przykład nieudanego testu:

print 'Mnożenie ok
' if multi(2,3) == 6;
die 'FAIL' if multi(2,0) != 0;

Przykłady rzeczywistych błędów z powodu braku wiedzy na ten temat

Historia

W starym projekcie testy były pisane "ręcznie" przez die i print. Nie było możliwe zautomatyzowanie integracji modułów CPAN — skrypty nie zwracały wyraźnych statusów, przez co błędy testowania były przeoczane w wydaniach.

Historia

Próba połączenia użycia Test::Simple i Test::More bez uwzględnienia struktury TAP (Test Anything Protocol) doprowadziła do zaburzenia wyników i złamania automatycznego systemu testowania. Konieczna była przebudowa infrastruktury testowej.

Historia

Brak dobrego pokrycia testami Test::Exception spowodował przeoczenie wielu błędów w obsłudze danych wejściowych: jeden z modułów niepoprawnie wyrzucał wyjątki, co nie zostało wykryte w trakcie testowania, błąd trafił do produkcji.