Akıllı sözleşmeler değişmez programlardır: Bir sözleşme uygulamaya konulduktan sonra değiştirilemez. Bu, kullanıcıların fonlarının işletildiği kuralların değiştirilmeyeceğinden emin olmalarını sağlar. Ancak, aynı özellik güvenli akıllı sözleşmeler oluşturmayı son derece karmaşık hale getirir. Eğer bir hata ya da güvenlik açığı içeren bir sözleşme yaratırsanız, bu sonsuza dek orada kalır. Bu nedenle testler, akıllı sözleşmeler için geleneksel uygulamalara kıyasla çok daha önemlidir.

İlgili: Akıllı Sözleşme Nedir? Başlangıç Rehberi

Test neden gereklidir?

Öncelikle, testlerin hangi sorunları çözebileceğini ve çözemeyeceğini açıklığa kavuşturalım. Bu amaçla, hatalar ve güvenlik açıkları arasındaki şu farka dikkat çekelim:

→ Eğer bir sorun planlanan bir senaryonun çalışmamasına yol açıyorsa, bu bir hatadır.

→ Eğer bir sorun planlanmamış bir senaryonun çalışmasına yol açıyorsa, bu bir güvenlik açığıdır.

Testler güvenlik açıklarını engellemez. Güvenlik açığı tanımı gereği planlanmamış bir şeydir, bu nedenle test aşamasında dikkate alamazsınız. Güvenlik açıklarıyla başa çıkmak için, bu makalenin sonunda açıklanan başka araçlara ve eylemlere ihtiyacınız vardır.

Testler, planlanan tüm senaryoların amaçlandığı gibi çalıştığından emin olmamıza yardımcı olur. Başka bir deyişle, testler hataların önlenmesine yardımcı olur. Bu gerçeğin birkaç önemli sonucu vardır:

• Temel kural: İş mantığının her satırına karşılık gelen bir test olmalıdır. İş mantığında bir senaryonuz varsa, kodda da olacaktır, bu da onu test etmeniz gerektiği anlamına gelir.
• En önemli senaryolar en kapsamlı şekilde test edilmelidir. Çoğu kullanıcı tarafından çalıştırılacak olan veya kritik işlevsellik uygulayan senaryolar daha fazla dikkat gerektirir.
• Testler aptalca hataları yakalar. Aptalca hatalar deneyimli geliştiriciler tarafından bile yapılır ve çok tehlikeli olabilir.
• Testler uç durumlar için harikadır. Bir kullanıcı sıfır token satın almaya çalışırsa ne olur? Kullanıcı sayısı sınıra ulaşırsa ne olur? Bu durumlar göz önünde bulundurulmalıdır ve bu görev için en iyi çözüm testleri kullanmaktır.
• Testleri oluşturmak için projeniz için ayrıntılı bir spesifikasyona sahip olmanız gerekir. Bu noktayı daha ayrıntılı olarak tartışalım.

Şartlar

Neyin planlandığını bilmiyorsanız planlanan bir senaryoyu test edemezsiniz. Bu yüzden bir spesifikasyon oluşturmanız gerekir.

Bu çok açık görünüyor, ancak birçok blockchain ekibi bu kuralı çiğniyor. Bir beyaz kağıt yazıyorlar ve hemen ardından kod yazıyorlar. Bu, istenen işlevselliğin yanlış uygulanmasına yol açabilir ve genellikle de açar. Hatta bir noktada ekip, sistemin nasıl davranmasını istediklerini kendilerinin de anlamadığı sonucuna varabilir. Dahası, istenen işlevsellik kendi içinde tutarlı olmayabilir ve dolayısıyla uygulanamayabilir.

Dolayısıyla, bir spesifikasyon şarttır. Bu bizi ilginç bir gözleme götürüyor: Kodunuzu test etmeye başladığınızda, sadece testler elde etmezsiniz. Tüm geliştirme prosedürünüzü iyileştirmeniz gerekir. İlk başta beklediğinizden daha fazla çalışırsınız, ancak aynı zamanda daha fazla fayda sağlarsınız.

Test için araçlar

Test tamamen ayrı bir bilgi dalıdır, bu nedenle bunu tek bir makalede ele almayacağım. Ancak, ilk gerekli araçları sayacağım.

Akıllı sözleşmelerinizi kolay ve doğru bir şekilde test etmek için bir test çerçevesine ihtiyacınız olacaktır. Meslektaşlarım aşağıdakilerden birini kullanmanızı öneriyor: Truffle, Embark ya da Etherlime.

Ayrıca, test kapsamını ölçmeniz gerekecektir. Test kapsamı, testler tarafından kapsanan kodun bir yüzdesidir, bu nedenle %100 kapsam, her bytecode komutunun test edildiği anlamına gelir. Ancak bu ideal bir durumdur, gerçek bir durum değildir. Pratikte, kaç test oluşturduğunuza bağlı olarak bu sayı her zaman 100’ün altında olacaktır. Test kapsamını ölçmek için en popüler araçlardan bazıları şunlardır: solidity-coverage ve @0x/sol-coverage.

Bağlamın genişletilmesi

Yani, test kapsamı %95 ise ve tüm kritik işlevler için testlerim varsa, kodumun güvenli olduğunu düşünebilirim, değil mi? Ancak doğru cevap, “Yanlış!” Test, gerekli güvenlik prosedürlerinden yalnızca bir tanesidir. Bu diyagrama bir göz atın:

Kodunuzu yazmaya başladığınızda, öncelikle kodu açık ve okunabilir hale getirmek için bir linter kullanmanız gerekir. Ardından planlanan tüm senaryoların doğru çalıştığından emin olmak için testlere ihtiyacınız vardır. Ardından standart ve kolayca tespit edilebilen güvenlik açıklarını bulmak için güvenlik araçlarını çalıştırırsınız. Bunları koddan kaldırdıktan sonra, kodun dış denetimine geçebilirsiniz. Geliştirmenin her aşamasında, kod tasarımı güvenlik için olduğu kadar kullanılabilirlik için de çok önemli olacaktır.

Tüm bu adımların kendi komplikasyonları vardır, ancak bunlar bu makalenin kapsamı dışındadır.

Burada ifade edilen görüşler, düşünceler ve fikirler yalnızca yazara aittir ve Cointelegraph’ın görüş ve fikirlerini yansıtmak veya temsil etmek zorunda değildir.