5 puan yazan GN⁺ 2025-01-17 | 1 yorum | WhatsApp'ta paylaş
  • rqlite, Go ile yazılmış, SQLite ve Raft üzerine geliştirilmiş hafif, açık kaynaklı, dağıtık ilişkisel bir veritabanıdır
  • Geliştirmesine 2014'te başlandı; güvenilirlik ve kaliteye öncelik veriyor ve 10 yılı aşkın geliştirme ile dağıtımdan sonra bile prodüksiyon ortamında 10'dan az panic vakası raporlandı
  • Dağıtık sistem testleri, birden çok katmanda dikkatli değerlendirme gerektirir ve sadelik içinde kaliteyi koruma felsefesini izler

Test piramidi: etkili bir yaklaşım

  • rqlite testleri "test piramidi"ne uyar
    • Test piramidi: birim testlerini temel alan, entegrasyon testleri ve en az düzeyde uçtan uca testler (E2E) içeren yapı
  • Verimli, hata ayıklaması kolay ve hedef odaklı bir test paketi sunar

Birim testleri: kalitenin çekirdeği

  • Birim testleri bağımsız bileşenleri sınar ve hız ile doğruluk arasında denge sağlar
  • SQLite ve "shared nothing" mimarisi sayesinde işlevlerin büyük kısmı birim testleriyle kapsanabilir
  • Tüm rqlite kodunun (yaklaşık 75.000 satır) içinde birim testleri yaklaşık 27.000 satırdan oluşur
  • Testler birkaç dakika içinde tamamlanır; bu da geliştirme sırasında sık test çalıştırmayı mümkün kılar

Sistem düzeyi testler: konsensüsü doğrulama

  • Sistem düzeyi testler, Raft konsensüs modülü ile SQLite arasındaki etkileşimi doğrular
  • Başlıca test maddeleri:
    • SQLite ifadelerinin düğümler arasında çoğaltılması
    • Farklı tutarlılık seviyelerinde okuma işlemleri
    • Küme arızasından kurtarma ve lider seçiminin doğrulanması
  • Yaklaşık 7000 satır test koduyla tek düğümlü ve çok düğümlü yapılandırmalardaki etkileşimler kapsamlı biçimde kapsanır

Uçtan uca testler: minimum katman

  • Uçtan uca testler, sistemin başlatılması, kümelenme ve temel davranışları doğrulayan bir smoke test işlevi görür
  • Python ile yazılmıştır ve gerçek bir rqlite kümesini çalıştırarak temel işlevleri doğrular
  • Örnek: AWS S3'e yedekleme doğrulaması
  • Yaklaşık 5000 satır test koduyla, hata ayıklama maliyetini en aza indiren sınırlı bir yaklaşım kullanılır

Performans testleri: sınırları zorlama

  • Performans testleri şu metrikleri değerlendirir:
    • Maksimum INSERT hızı
    • Eşzamanlı sorgu işleme
    • Bellek, CPU ve disk kullanımının karşılaştırılması
  • 2 GB'tan büyük SQLite veritabanı testleri de dahil edilerek bellek yönetimi ve disk yazma darboğazları analiz edilir
  • Performans sorunları bulunur ve optimizasyon yoluyla kararlılık güvence altına alınır

Öğrenilen dersler

  • Teste en baştan başlayın
    • Birim testleri, sisteme güven inşa etmenin en etkili yoludur
    • Geliştirme sırasında birim testi yazmayı ertelememek gerekir; çünkü hatalar entegrasyon veya E2E testlerine göre daha hızlı bulunabilir
  • Test kodunu basit tutun
    • Test paketi, karmaşık refactoring yapmak ya da DRY (Don't Repeat Yourself) ilkesine katı biçimde uymak için uygun bir yer değildir
    • Anlaşılması kolay kod yazmak önemlidir; ek boilerplate koda da izin verilmelidir
  • Testleri doğrulayın
    • Test yazarken, beklenen sonucu geçici olarak tersine çevirip testi yeniden çalıştırın
    • Doğru yazılmış bir test bu durumda başarısız olmalıdır; bu da test kodundaki hataları önceden önlemeye yardımcı olur
  • Test başarısızlıklarını görmezden gelmeyin
    • Anlaması zor ya da nadir görülen test başarısızlıkları bile yazılım hakkında önemli bilgiler sağlar
    • Hata ayıklaması zor başarısızlık vakaları, çoğu zaman koddaki kritik kusurları keşfetmek için fırsat olabilir
  • Determinizmi en üst düzeye çıkarın
    • Sistemin otomatik süreçlerini elle çalıştırmaya imkân veren mekanizmalar kurun
    • Örnek: Raft snapshot özelliği normalde yarı otomatik çalışsa da, test sırasında açıkça tetiklenebilecek şekilde tasarlanmıştır
  • Bilinçli hareket edin (Be Deliberate)
    • Daha üst seviye entegrasyon veya E2E testleri, yalnızca gerekliliği açıkça kanıtlandığında eklenmelidir
    • Aşırı test, geliştirme ve hata ayıklama hızını düşürebilir
  • Uygulayın ve yineleyin
    • Performans testlerinde fsync çağrıları temel darboğaz olarak saptandı; bunun ardından Raft log girdileri diske yazılmadan önce sıkıştırılarak disk kullanımı optimize edildi
  • Verimliliğe odaklanın
    • Birkaç dakika içinde çalışabilen bir test paketi koruyarak hızlı yinelemeli geliştirme mümkün olur
    • Bu, açık kaynak bir projeyi sürdürmek ve canlı tutmak için kritik bir avantajdır

Önce kalite

  • Test piramidine uyulur ve her test katmanının net bir amacı olacak şekilde tasarlanır
  • Dağıtık sistemlerin karmaşıklığı arttıkça, testlerde sadeliği korumak kilit önem taşır
  • Hedef, güvenilir ve işletmesi kolay bir veritabanı oluşturmaktır

1 yorum

 
GN⁺ 2025-01-17
Hacker News görüşü
  • İlk test en zoru ama eklemeye değer. Sonraki testler daha kolay hale geliyor

    • Parametreli testler tekrar eden kodu azaltır ve çeşitli testleri mümkün kılar
    • Kısıtların kapsamlı şekilde doğrulanabildiği durumlarda faydalıdır
    • Prop testleri tutarlılığı ve değişmezleri doğrulamaya yardımcı olur
    • Gerçekten test yapıp yapmadığınızı doğrulamak için mutasyon testini kullanmak önemlidir
  • Projeye olan bağlılık etkileyici

  • Test piramidi anlaşılır, ancak çoğu zaman tüm seviyeler mevcut olmuyor ve bunun hızla iyileştirilmesi gerekiyor

    • Birden fazla ekiple çalışıldığında e2e katmanını doldurmak kimsenin üstlenmediği bir işe dönüşüyor
    • Auth0 gibi kimlik doğrulama mekanizmaları kullanıldığında test etmek zorlaşıyor
    • e2e testleri yoksa sistem kolayca bozulabiliyor
    • Otomatikleştirilmiş e2e testleri sorunları kolayca tespit etmeyi ve geri almayı mümkün kılıyor
  • SSS bölümünde kopyala-yapıştır hatası var gibi görünüyor

  • Jepsen raporunu bekliyor

  • Video formatında da keyifle izlemiş

  • Performans testi kurulumunu kıskanıyor

  • rqlite kullanmış ve sadeliğini iyi aktardığını düşünüyor

  • Deterministik simülasyon testleri hakkında görüş soruyor

  • rqlite'ın gerçek ortamda kullanılıp kullanılmadığını merak ediyor

  • rqlite özgün ve dahiyane bir proje