Bu çevirinin orijinali “Mutation Testing For Move: Improve Your Unit Tests” adlı yazıya buradan ulaşabilirsiniz.
Özet
Değerli varlıkları işleyen kontratlar için kapsamlı testler çok önemlidir. Peki testlerinizin yeterince iyi olduğunu nasıl anlayabilirsiniz? Move Mutation Tester, bir test paketindeki kör noktaları otomatik olarak bulan Move araç setindeki yeni bir araçtır.
Giriş
İyi birim testlerine sahip olmak, yazılımın doğruluğunu sağlamak ve amaçlanan davranışı göstermek için önemlidir. Gerçekten de, bunlar modern yazılım mühendisliğinde beklenen uygulamalardan biridir. Ayrıca, yazılımı yüksek bir güvenle geliştirmek için de gereklidirler: kodun değiştirilmesi (yeni bir davranış eklemek veya bir hatayı düzeltmek için) amaçlanan davranışı bozmaz.
Kod kapsamını ölçmek, birim testlerinin kalitesini değerlendirmek için birincil yöntemdir. Aptos CLI, en iyi uygulama olarak önerdiğimiz bir kapsam aracına sahiptir. Ancak, kod kapsamı yalnızca bir kod satırının birim testleri tarafından kapsanıp kapsanmadığını ölçer, fakat birim testlerinin test edilen kod üzerinde doğru anlamsal kontrolleri yapıp yapmadığını ölçmez. Önceki bir blogda, kod kapsamının birim testlerinin kalitesini ölçmek için neden yetersiz olduğunu gösterdik.
Mutasyon testi, birim testlerindeki kör noktaları bulmaya yönelik bir tekniktir ve kapsam araçlarından çok daha ileri gider. Kaynak koda hatalar enjekte eder ve birim testlerinin bu hataları tespit edip edemediğini kontrol eder. Artık move-mutation-test aracının ilk sürümüne sahibiz (buradan erişilebilir, Eiger’daki iş ortaklarımız tarafından geliştirilmiştir). Move birim testlerinin kalitesini değerlendirir ve bunu Move projelerinizde denemenizi ve bize geri bildirim vermenizi çok isteriz.
Araç nasıl çalışır?
Araç iki adımda çalışır:
- Orijinal kaynak kodunu çeşitli şekillerde mutasyona uğratır. Her mutasyona uğramış versiyona mutant denir.
- Araç daha sonra her mutant için (değiştirilmemiş) birim testlerini çalıştırır. Mutantların birim testi hatalarına neden olmasını bekleriz. İki sonuç mümkündür:
- Mutantlar testleri geçemez. Bu mutantlara öldürülmüş mutantlar denir. Testlerin enjekte edilen hataları yakaladığını gösterirler.
- Testler mutant için başarılı olur (canlı mutant olarak adlandırılır). Bu, testlerde potansiyel bir kör noktaya işaret eder.
Mutasyon test aracı raporu çok sayıda canlı mutantla doluysa, birim testlerini iyileştirmeyi düşünmek gerekir.
Aracın kullanımına ilişkin örnek uygulama
Aracın nasıl kullanılabileceğini göstermek için gerçek dünyadaki bir projede küçük bir uygulama yapalım. aptos-stdlib projesini kullanacağız.
Aracın iki ana alt komutu vardır:
move-mutation-test run(aracı çalıştırır ve bir rapor üretir),move-mutation-test display-report(sonuçları güzelce görüntüler)
Araç, tüm proje için çok sayıda mutant üretebilir ve her mutant üzerinde testlerin çalıştırılması nispeten yavaş olabilir. Önerilen kullanım şekli, daha yönlendirilmiş ve spesifik olmaktır, yani modül bazında veya fonksiyon bazında kullanmaktır.
Mutantları oluşturmak için fixed_point64 modülünü seçelim. Birim test kapsamı eksikliği nedeniyle kesinlikle hayatta kalacak mutantlar üretmekten kaçınalım, --coverage bayrağını kullanarak mutasyona uğramış kodun yalnızca uygun birim test kapsamına sahip kod parçaları üzerinde üretilmesini sağlayalım.
Not: --coverage bayrağını kullanmak için, kullanıcının önce aptos move test --coverage komutunu çalıştırarak proje dosyaları içinde yerel olarak saklanan birim test kapsamı raporunu oluşturması gerekir. Aşağıda, bu komutun zaten çalıştırılmış olduğunu varsayıyoruz.
move-mutation-test run --coverage --output report.txt --mutate-modules fixed_point64
Bu komut çalıştırıldığında modüldeki her fonksiyon için canlı mutant sayısını gösteren kısa bir özet görmeliyiz.
Yukarıdaki rapordan round fonksiyonunun dokuz canlı mutanta sahip olduğunu gözlemleyebiliriz. Sonuçları daha detaylı incelemek için aşağıdaki komutu kullanalım:
move-mutation-test display-report coverage --path-to-report report.txt
Daha aşağıya kaydırırsak mutasyon testi kapsamını görebileceğimiz round fonksiyonunu buluruz: öldürülen/toplam mutantlarla ilgili bilgi içeren satırlar:
İdeal senaryonun mutantların tümünün/çoğunun öldürülmesi olduğunu unutmayın. Bu, fonksiyonun mutasyon testi kapsamına basit bir genel bakıştır, ancak hangi mutantların hayatta kaldığını bize söylemez. Bu amaçla, mutants alt komutunu kullanabiliriz:
move-mutation-test display-report mutants --modules fixed_point64 --functions round
Bir sonraki adım olarak bu mutantların testleri geçememesi için birim testlerini nasıl iyileştirebileceğimizi görelim.
Yukarıdakilerden round fonksiyonu için testlerin daha da iyileştirilebileceğini görebiliriz. Bu testleri aşağıdakilerle geliştirmeye çalışalım:
Şimdi aracı yeniden çalıştırabiliriz. Bu sefer yürütmeyi daha kısa tutmak için daha spesifik olalım ve yalnızca round fonksiyonunu aşağıdaki komutla mutasyona uğratalım:
move-mutation-test run --coverage --output report.txt --mutate-modules fixed_point64 --mutate-functions round
Özet rapordan bu fonksiyona ilişkin istatistiklerin iyileştiğini şimdiden görebiliyoruz!
Kapsamı display-report coverage komutuyla tekrar kontrol edelim:
move-mutation-test display-report coverage
Şimdi mutasyon testi kapsamı iyileşti (daha fazla mutant öldürüldü) ve testlerimizin kalitesi arttı.
Yukarıdaki çıktı birim test kapsamı raporuna benzer. Toplam mutant sayısına karşılık öldürülen mutant sayısı için satır başına istatistikleri gösterir.
Sonuç
Mutasyon testi, birim testlerinin kalitesine dair içgörü elde etmek için kod kapsamı aracını tamamlar. Birim testlerindeki kör noktaları bulabilir ve böylece kaynak koddaki hataları da potansiyel olarak belirleyebilir. Özellikle yüksek güven gerektiren Move kontratları için denemenizi öneririz.
Her yerde %100 kod kapsamı elde etmeye çalışmanın faydalı olmayabileceği gibi (hatta bazen zararlı olabilir çünkü birim testlerinin çok kırılgan olmasına neden olabilir), %100 mutasyon testi kapsamı elde etmenin de sizi yanlış yola sürükleyebileceğini unutmayın. Mutasyon testi sonuçları rehber olarak kullanılmalıdır ve testlerin iyileştirilmesi için, kod tabanının hangi bölümlerine daha fazla dikkat edilmesi gerektiğini belirlemek için projeye özgü değerlendirmeler kullanılmalıdır.