ProgramlamaPerl geliştirici, test mühendisi

Perl'de test etme nasıl çalışır: hangi yerleşik ve üçüncü taraf test modülleri mevcuttur, bunlar nasıl farklılık gösterir ve Perl projelerinde hangi test uygulamaları yaygın olarak kullanılmaktadır?

Hintsage yapay zeka asistanı ile mülakatları geçin

Cevap

Perl'de geleneksel olarak test etme için modül paketleri kullanılmaktadır: Test::Simple, Test::More ve Test::Class, Test::Most gibi kapsamlı çerçeveler. Temel olanı Test::More'dır — bu, eşitlik kontrolleri, yapı karşılaştırmaları, istisna atma testi gibi zengin bir fonksiyon paketi sunar.

Popüler modüllerin sınıflandırılması:

  • Test::Simple — tamamen basit, başlangıç testleri için;
  • Test::More — çoğu proje için de facto standart;
  • Test::Exception, Test::Deep, Test::Warn — ek yönleri kontrol etmek için (istisnalar, iç içe yapılar, uyarılar);
  • Test::Class, Test::Class::Moose — nesne yönelimli yaklaşımlar.

Test::More ile test örneği:

use Test::More tests => 2; is(2 + 2, 4, 'Toplama çalışıyor'); like('foo_bar', qr/foo/, 'foo var');

En iyi uygulamalar:

  • Tüm kamu modülleri t/-dizininde otomatik testlere sahip olmalıdır.
  • Test verilerini prodüksiyon koduyla karıştırmamak.
  • Modüler, entegrasyon, bazen de property-based testler uygulamak.

Kandırmaca soru

Perl'de Test::* modüllerini kullanmadan sadece die/print yapıları kullanarak kendi testlerinizi yazabilir misiniz? Bu yaklaşımda hangi riskler vardır?

Cevap: Resmi olarak evet — sonuçları göstermek için print ve die kullanarak kendi "testlerinizi" yazabilirsiniz. Ancak bu durumda otomasyonu doğru bir şekilde oluşturamazsınız: TAP/CPAN entegrasyonları desteklenmez, rapor oluşturmak ve çok sayıda testi analiz etmek zordur, test tabanını ölçeklendirmek ve sürdürmek zorlaşır.

Başarısız test örneği:

print 'Çarpma başarılı ' if multi(2,3) == 6; die 'HATA' if multi(2,0) != 0;

Konunun inceliklerini bilmemekten kaynaklanan gerçek hatalara dair örnekler


Hikaye

Eski bir projede testler "elle" die ve print aracılığıyla yazılmıştı. CPAN modüllerinin otomatik olarak entegrasyonu mümkün değildi — skriptler net durumlar döndürmediği için test hataları sürümlerde gözden kaçıyordu.


Hikaye

Test::Simple ve Test::More kullanımlarının TAP (Test Anything Protocol) yapısını dikkate almadan karıştırılması, otomatik test sisteminin çıktısını bozmuştur. Test altyapısının yeniden yapılandırılması gerekiyordu.


Hikaye

Test::Exception ile iyi bir test kapsamının olmaması, giriş verileri işleme hatalarının gözden kaçmasına yol açtı: modüllerden biri yanlış bir şekilde istisnalar atıyordu, bu test sırasında tespit edilmedi ve hata prodüksiyona girdi.