Aptallar için akıllı sözleşme testi mi geliyor? Akıllı sözleşmeler, değiştirilemeyen içeriğe sahip programlardır. Bir sözleşme, taraflara ulaştıktan ve kabul edildikten sonra değiştirilemez. Bunun nedeni, tarafların emin olması içindir. Fonların işletileceği kuralların selameti için önemlidir. Burada ortaya karmaşık bir hal çıkıyor.
Bu karmaşayı ortaya çıkaran, güven temel tabanlı akıllı sözleşmelerin oluşturulmasıdır. Hata içeren yahut ta güvenlik açığı olan sözleşmelerin ortaya çıkarılması sözleşme süresince Demokles’in Kılıcı gibi başınızın üstünde duracaktır. Bundan ötürü de akıllı sözleşmeler için test, geleneksel uygulamalardakinden daha önemlidir.
Test niçin gereklidir
İlk olarak, testlerin üstesinden gelebildiği ve çözüme kavuşturduğu ve kavuşturamadığı sorunlar olarak ayırmak gerekir. Hatalar ve güvenlik açıkları arasında neler zikredilebilir?
→ Şayet ortaya çıkan sorun planlanan programın akışına mani oluyorsa burada bir hata oluşmuş demektir.
→ Şayet sorun planlanmayan bir senaryoya yol açıyorsa bunun tanımı da güvenlik açığıdır.
Yapılan testler, programdaki güvenlik açıklarını engelleyemezler. Zira güvenlik açığının tanımında planlanmayan sorun yer alır. Güvenlik açıkları ile başa çıkmak için başka araçlara ihtiyaç vardır. Test aşaması güvenlik açıklarının çözüm yeri değildir.
Test, plan dâhilindeki işleyişin planlandığı gibi gitmesini sağlayan bir yardımcı araçtır. Diğer bir söylemle testler, hataları görmeye ve önlemeye yardım eder. Bunun da bazı kuralları vardır. En temel kural, her işin mantıklı bir testi olmalıdır. Test ise her satıra karşılık gelen bir test şeklinde oluşturulmalıdır. İşin mantığında bir senaryo yer alıyorsa, o zaman bunun test edilmesi gerekir. Kod da testte kullanılmalıdır.
Senaryoların önemine göre kapsamlı test edilmesi
Kullanıcı sayısı fazla olan ve kritik amaçlar için kullanılacak uygulamalar, ilave dikkat gerektirir. Testlerin en önemli özelliği, aptalca yapılan hataları görmeyi sağlar. Aptal olarak nitelendirilen hatalar, son derece deneyim sahibi geliştiriciler tarafından dahi yapılmaktadır. Ayrıca bu hatalar çok tehlikeli boyutlarda da olabilir.
Testler, kenar durumlarda harika durumdadır. Kullanıcıların ücretsiz token alma çabası nasıl görülür? Kullanıcı sayısı doyuma ulaştığında durum ne olur? Gibi sorular dikkate alınmalıdır. Bunun için de her görev için en iyi çözüm testleri kullanılmalıdır. Ayrıca ayrıntılı özelliklere sahip olmak için yapılması gerekli olan projeye dair testler kurgulanmasıdır.
Şartnamenin özellikleri
Planlama yapmayı ve neyin planlandığını bilmeyen planlanan bir senaryoyu da test edemez. Senaryo şartlarının öncelikle oluşturulması önemlidir. Nedense bu açık görünen durum çoğu Blockchain ekibi tarafından göz ardı ediliyor. Yapılan ilk iş beyaz bir kağıda hemen kod yazmaya başlamak oluyor. Elbet bu olacak ancak bu genellikle istenen işlevselliğin yanlış uygulanmasına neden olmaktadır.
Ekip, sistemin nasıl davranması gerektiğinden anlamayan bir noktada olabilir. Dahası, istenen işlev kendisi ile tutarlı olmayadabilir. Yani anlaşılan o ki şartname zorunluluktur. Bu da ilginç bir gözleme yönlendirir. Yazılan kod test edilmeye başlandığında yalnızca testler alınmaz. Tüm gelişim izleğinin de geliştirilmelidir. Bu yol ile umulandan daha fazla çalışıyor olunabilinir ancak yarar noktasında daha fazla fayda içerir.
Aptallar için akıllı sözleşme testi
Test her şeyiyle ayrı bir bilim dalıdır. Bundan dolayı tek bir makale yeterli olmayacaktır. Bu makalede, öncelikli gerekli olan araçlar ve adımlardan bahsedilecektir. Akıllı sözleşmeleri hem kolay hem de doğru bir şekilde test etmek için öncelikle bir test çerçevesine ihtiyaç olunacaktır. Bunun için işin uzmanı; Truffle, Embark veya Etherlime’den birini kullanmayı önerir.
Atılacak adımlardan biri de, test kapsamının ölçülmesidir. Test kapsamı, testlerle kapsanan kodların yüzdesidir. Yüzde yüz kapsam, her bayt kodu talimatının test edilmesi demektir. Lakin bu durum, ideal bir durum da değildir. Uygulamada yer alacak testlerin miktarına bağlı olarak bu rakam, daima yüzde yüzün altında yer alacaktır.
Testin kapsamını da ölçecek araçlar vardır. En popülerleri solidity-coverage ile @0x/sol-coverage. araçlarıdır. Bağlamı genişletmenin de yolları vardır. Eğer testin kapsamı yüzde doksan beşi buluyorsa ve bütün kritik işlevler adına da testler varsa, sahip olunan kodun güvenli olduğu anlamı mı söz konusudur? Ancak doğru cevap yanlış test gerekli güvenlik izleklerinden yalnızca bir tanesidir. Şema aşağıdadır.
İlgili kod yazılmaya başlanıldığında linter kullanılmak gerekir. Zira bu kodun hem net hem de okunabilir olmasını sağlar. Bundan sonra plan dâhilindeki tüm senaryoların doğru çalıştığından emin olmak gerekir. Emin olmak için de testlere ihtiyaç vardır.
Bu aşamadan sonra da standart ve kolayca algılanabilen güvenlik açıklarının bulması için güvenlik araçları çalıştırılmalıdır. Bunlar, koddan kaldırıldıktan sonra kodun dış denetimine geçilir. Geliştirmenin her aşamasında kod tasarımı hem güvenlik hem de kullanılabilirlik açısından çok önemli olacaktır. Bütün bu adımların komplikasyonları vardır.
