ProgrammierungPerl-Entwickler, Testingenieur

Wie funktioniert das Testen in Perl: welche integrierten und externen Testmodule gibt es, worin unterscheiden sie sich und welche Testpraktiken werden in Perl-Projekten häufig verwendet?

Bestehen Sie Vorstellungsgespräche mit dem Hintsage-KI-Assistenten

Antwort

In Perl wird traditionell ein Paketmodul zum Testen verwendet: Test::Simple, Test::More sowie komplexe Frameworks wie Test::Class, Test::Most. Das Grundmodul ist Test::More — es bietet eine umfangreiche Sammlung von Funktionen: Gleichheitsprüfungen, Strukturvergleiche, Tests auf Ausnahmen usw.

Klassifizierung beliebter Module:

  • Test::Simple — für sehr einfache, grundlegende Tests;
  • Test::More — der De-facto-Standard für die meisten Projekte;
  • Test::Exception, Test::Deep, Test::Warn — zur Überprüfung zusätzlicher Aspekte (Ausnahmen, verschachtelte Strukturen, Warnungen);
  • Test::Class, Test::Class::Moose — objektorientierte Ansätze.

Beispieltest mit Test::More:

use Test::More tests => 2; is(2 + 2, 4, 'Summe funktioniert'); like('foo_bar', qr/foo/, 'Es gibt foo');

Best Practices:

  • Alle öffentlichen Module sollten Autobewertungen im t/-Verzeichnis haben.
  • Testdaten sollten nicht mit Produktionscode vermischt werden.
  • Modultests, Integrationstests und manchmal Property-basierte Tests anwenden.

Fangfrage

Kann man eigene Tests in Perl ohne Verwendung von Modulen Test::*, nur mit den Konstruktionen die/print schreiben? Welche Risiken gibt es bei diesem Ansatz?

Antwort: Formal ja — man kann eigene "Tests" schreiben, indem man print und die zur Ausgabe des Ergebnisses verwendet. In diesem Fall wird jedoch kein korrekter Ansatz zur Automatisierung umgesetzt: TAP/CPAN-Integrationen werden nicht unterstützt, das Erstellen von Berichten und die Analyse vieler Tests wird schwierig, Skalierung und Wartung der Testbasis sind problematisch.

Beispiel eines misslungenen Tests:

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

Beispiele realer Fehler aufgrund mangelnder Kenntnisse des Themas


Geschichte

In einem alten Projekt wurden Tests "manuell" über die Funktionen die und print geschrieben. Es war unmöglich, die CPAN-Modulinstallation automatisch zu integrieren — die Skripte gaben keine klaren Status zurück, wodurch Testfehler in den Releases übersehen wurden.


Geschichte

Der Versuch, Test::Simple und Test::More ohne Berücksichtigung der TAP (Test Anything Protocol)-Struktur zu mischen, führte zu einer fehlerhaften Ausgabe des automatischen Testsystems. Es war notwendig, die Testinfrastruktur neu zu gestalten.


Geschichte

Das Fehlen einer guten Testabdeckung mit Test::Exception führte dazu, dass eine Reihe von Fehlern bei der Verarbeitung von Eingabedaten übersehen wurden: einer der Module warf Ausnahmen nicht korrekt, dies wurde während der Tests nicht entdeckt und der Bug gelangte in die Produktion.