Yazılım geliştirmenin amacı, amaçlandığı gibi çalışmasını sağlamaktır. Bunu başarmak için birden fazla test iterasyonu gereklidir ve eldeki görevi mümkün olan en kısa sürede tamamlamaya çalışırken iterasyonlar arasındaki süre kritik öneme sahiptir.
Origin'de geliştirme için birim ve çatal testleri kullanıyoruz. Çatal testlerini çalıştırmak sıkıcı bir şekilde yavaş olabilir, ancak çatal testlerinin yürütme süresini (bazı durumlarda) 4 kat azaltmayı başardık. Bu makalede, çatal testlerinizin hızını nasıl artırabileceğinizi açıklayacağım, böylece kodunuzu kısa sürede amaçlandığı gibi çalıştırabilirsiniz.
Tipik olarak, çatal testi mi yoksa birim testi mi kullanacağınız, geliştirilen protokolün mimarisine bağlıdır. Bazı ekipler yalnızca birim testleri kullanırken bazıları hem birim hem de çatal testleri kullanır. Origin'de sözleşmelerimiz çeşitli 3. taraf protokollerle (Curve, Uniswap, Balancer, Convex...) etkileşim halindedir ve entegrasyondaki hatalar feci fon kayıplarına neden olabilir.
Birim testlerini kullanarak, 3. taraf protokolün ABI'sini taklit ediyor ve sözleşmelerimizin programatik olarak doğru şekilde entegre olduğunu test ediyoruz. Ancak 3. taraf bir protokolün davranışını tüm incelikleriyle ve protokolün içinde bulunabileceği çeşitli (meşru veya manipüle edilmiş) durumlarla test etmek, çatal testlerinin parladığı yerdir. Ekibimizdeki bazı mühendisler için çatal testleri kullanarak test odaklı geliştirme, birincil geliştirme modudur. "Kod değişikliği" ile "test yürütme" süresini azaltmak çok önemlidir.
Origin'de Solidity geliştirme yığınımız için Hardhat kullanıyoruz. Geliştirme döngüsü süresini kısaltmak için bir fork test çalışmasının hangi adımlardan oluştuğunu anlamamız önemlidir. Basit olması için, bir seferde yalnızca 1 çatal testi çalıştıracağız - akıllı bir sözleşme üzerinde çalışırken genellikle yaklaşım budur.
En yavaş yaklaşım, çatal testlerini en son bloktan düğüm çatallamasıyla çalıştırmaktır. Bu şekilde, testler her çalıştırıldığında farklı bir blok yüksekliği seçilir ve hardhat, ana ağ sağlayıcısından depolama yuvalarını okuyarak herhangi bir önbellekleme yapamaz. Bu da 101 saniyelik yavaş yürütme hızına yansımaktadır.
Bu özel çatal testi, varlıkları bir Dengeleyici havuzuna dağıtan likidite madenciliği stratejilerimizden birine fon gönderir. Bu, çok sayıda depolama yuvası okumasına neden olur ve yürütmenin yavaş "test" kısmının ana nedenidir (yukarıdaki çubuğun turuncu kısmı).
Bariz düşük asılı meyve, blok yüksekliğini sabitlemektir, böylece Hardhat, depolama yuvası okumalarının yerel bir önbelleğini kullanarak büyük ölçüde zaman kazanabilir. Derleme süresi bu optimizasyondan etkilenmez, ancak diğer tüm adımlar etkilenir. Döngü süresini büyük ölçüde 27 saniyeye düşürür (bu, hardhat önbelleğinin zaten ısınmış olduğu testin ilk çalıştırmaları dışındaki tüm çalıştırmalar için geçerlidir).
Yukarıdaki yaklaşım durumu önemli ölçüde iyileştirir, ancak yine de birim testlerinin hızından uzaktır ve zaman zaman sinir bozucu derecede yavaş görünebilir. Sadece bir sözleşmeyi değiştirdik. İdeal olarak sadece 1 (veya daha fazla) solidity sözleşmesinin bayt kodunun değiştirilmesi gerekirken neden aynı dağıtımları ve dağıtım sonrasını yeniden çalıştırmamız gerekiyor? Elbette derlemeler arasında depolama yuvası düzenini veya durumunu değiştirmediğimiz göz önüne alındığında. Sıcak dağıtımlara girin.
Hot-deploy, değiştirilmekte olan sözleşmeyi dağıtır ve bayt kodunu alır. Hardhat test paketi anlık görüntülerini kullanarak, testler çalıştırılmadan önceki bir durumda bu sözleşmenin önceki sürümünü bulur ve bayt kodunu yeni derlenmiş olanla değiştirir. Bunun da ötesinde, tüm (post) dağıtım adımlarını atlayarak test fikstürlerini ve testin kendisini çalıştırır.
Döngü süresi artık sadece 7 saniyeye düştü. Geliştirme döngüsündeki bu değişiklik Origin Protocol'ün üretkenliğini ve özellik geliştirme hızını büyük ölçüde artırmasına yardımcı oldu.
Ne yazık ki, sıcak dağıtımlar bir anahtar olarak açılamıyor (en azından henüz değil) ve bazı yapılandırmalar gerektiriyor. Origin'de çözümü uygulama şeklimiz şu şekildedir:
Önemli bir gereklilik, bağımsız bir hardhat düğümünün fork test ortamından ayrı olarak çalışmasıdır. Hemen belli olmayabilir, ancak fork test çalıştırması başka bir düğüm çalışma zamanı oluşturacak ve diğer bağımsız çalışan düğümü bir sağlayıcı olarak kullanacaktır. Bağımsız düğüm tüm (post) dağıtımları çalıştıracak ve fork test düğümü değişiklikleri derleyecek, gerekli tüm sözleşme bayt kodlarını değiştirerek test fikstürlerini çalıştıracak ve son olarak testi çalıştıracaktır.
Dağıtım dosyalarındaki, sözleşme depolama yuvalarındaki ve bunların durum kurulumlarındaki değişiklikleri akılda tutmak iyidir. Test armatürlerini çalıştırmanın bağımsız düğümün yeniden başlatılmasını gerektirdiğini göz önünde bulundurmalısınız.
Bazen sırf daha hızlı geliştirebilmek için platformun 3. taraf protokollerle entegre olan kısımları için birim testleri kullanmak cazip gelebilir... bir çatal testinin sağlayabileceği ek güvenlik pahasına. Origin'deki geliştiriciler için sıcak dağıtımlar, bu döngü süresi boşluğunu kapatmak ve pastamızı hem yiyip hem de yemeye çalışmak için önemli bir adımdır. Umarım başkaları da bunu dener ve umarım siz de geliştirme döngü sürelerinizi kısaltmak için bu yaklaşımdan faydalanabilirsiniz.
