Hoe werkt testen in Perl: welke ingebouwde en externe testmodules zijn er, wat zijn de verschillen, en welke testpraktijken worden veel gebruikt in Perl-projecten?

Antwoord

In Perl wordt traditioneel een pakket van testmodules gebruikt: Test::Simple, Test::More, evenals complexe frameworks zoals Test::Class, Test::Most. De basis is Test::More — het biedt een rijke set functies: gelijkheidcontroles, structuurvergelijkingen, exceptiontesting, enz.

Classificatie van populaire modules:

• Test::Simple — voor heel simpele, basale tests;
• Test::More — de de facto standaard voor de meeste projecten;
• Test::Exception, Test::Deep, Test::Warn — voor het controleren van aanvullende aspecten (uitzonderingen, geneste structuren, waarschuwingen);
• Test::Class, Test::Class::Moose — objectgeoriënteerde benaderingen.

Voorbeeld van een test met Test::More:

use Test::More tests => 2;

is(2 + 2, 4, 'De som werkt');
like('foo_bar', qr/foo/, 'Er is foo');

Beste praktijken:

• Alle publieke modules moeten autotests hebben in de t/-directory.
• Testgegevens niet mengen met productiecode.
• Toepassen van unit-, integratie-, en soms property-based tests.

Vragen met een valstrik

Kun je je eigen tests in Perl schrijven zonder gebruik te maken van Test::* modules, alleen met behulp van de constructies die die/print? Wat zijn de risico's van deze aanpak?

Antwoord: Formeel ja — je kunt je eigen "tests" schrijven met gebruik van print en die voor het afdrukken van resultaten. Echter, in dat geval wordt er geen correcte benadering voor automatisering gevormd: TAP/CPAN-integraties worden niet ondersteund, rapportages en het analyseren van meerdere tests wordt moeilijk, en het schalen en onderhouden van de testbasis is bemoeilijkt.

Voorbeeld van een mislukte test:

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

Voorbeelden van echte fouten door onwetendheid over de nuances van het onderwerp

---

Verhaal

In een oud project werden tests "handmatig" geschreven via die en print. Automatische integratie van CPAN-modules was onmogelijk — scripts gaven geen duidelijke statussen terug, waardoor testfouten in releases werden gemist.

---

Verhaal

De poging om gebruik te mengen van Test::Simple en Test::More zonder rekening te houden met de structuur van TAP (Test Anything Protocol) leidde tot verstoringen in de uitvoer van de automatische testsysteem. Dit vereiste herontwerp van de testinfrastructuur.

---

Verhaal

Het ontbreken van goede testdekking bij Test::Exception veroorzaakte het missen van verschillende fouten in de verwerking van invoergegevens: een van de modules gooide incorrecte uitzonderingen, dit werd niet ontdekt tijdens het testen, en de bug belandde in productie.