rqlite अपनी testing कैसे करता है

• rqlite एक हल्का open source distributed relational database है, जिसे Go में लिखा गया है और SQLite व Raft पर आधारित होकर विकसित किया गया है
• इसका development 2014 से शुरू हुआ था, और reliability व quality को प्राथमिकता देते हुए 10 साल से अधिक development और deployment के बाद भी production environment में panic के 10 से कम मामले ही रिपोर्ट हुए हैं
• distributed system testing में कई layers पर सावधानीपूर्वक विचार की ज़रूरत होती है, और यह simplicity के भीतर quality बनाए रखने की philosophy का पालन करता है

टेस्ट पिरामिड: एक प्रभावी दृष्टिकोण

• rqlite की testing "test pyramid" का पालन करती है
  • test pyramid: unit tests को आधार बनाकर, integration tests और न्यूनतम end-to-end tests (E2E) शामिल करने वाली संरचना
• यह efficient, debug करने में आसान, और goal-oriented test suite प्रदान करता है

यूनिट टेस्ट: quality का केंद्र

• unit tests स्वतंत्र components को test करते हैं और speed व accuracy के बीच संतुलन प्रदान करते हैं
• SQLite और "shared nothing" architecture के आधार पर अधिकांश features को unit tests से cover किया जा सकता है
• पूरे rqlite code (लगभग 75,000 lines) में unit tests लगभग 27,000 lines हैं
• tests कुछ ही मिनटों में पूरे हो जाते हैं, जिससे development के दौरान बार-बार testing संभव होती है

सिस्टम-स्तरीय टेस्ट: consensus का सत्यापन

• system-level tests, Raft consensus module और SQLite के interaction का सत्यापन करते हैं
• मुख्य test items:
  • nodes के बीच SQLite statements की replication
  • अलग-अलग consistency levels पर read operations
  • cluster failure recovery और leader election का सत्यापन
• लगभग 7000 lines के test code से single-node और multi-node configurations के interactions को व्यापक रूप से cover किया जाता है

एंड-टू-एंड टेस्ट: न्यूनतम layer

• end-to-end tests system startup, clustering, और basic behavior की पुष्टि करने वाले smoke tests की भूमिका निभाते हैं
• ये Python में लिखे गए हैं और वास्तविक rqlite cluster चलाकर प्रमुख functions का सत्यापन करते हैं
• उदाहरण: AWS S3 में backup का सत्यापन
• लगभग 5000 lines के test code के साथ सीमित approach अपनाई गई है ताकि debugging cost न्यूनतम रहे

परफॉर्मेंस टेस्ट: सीमाओं की जांच

• performance tests निम्न metrics का मूल्यांकन करते हैं:
  • अधिकतम INSERT speed
  • concurrent query handling
  • memory, CPU, और disk usage की तुलना
• 2GB से बड़े SQLite databases की testing सहित memory management और disk write bottlenecks का विश्लेषण किया जाता है
• performance issues खोजकर और optimization के ज़रिए stability सुनिश्चित की जाती है

सीखे गए सबक

• शुरुआत से testing शुरू करें
  • unit tests system reliability बनाने का सबसे प्रभावी तरीका हैं
  • development के दौरान unit tests लिखना टालना नहीं चाहिए, क्योंकि bugs को integration tests या E2E tests की तुलना में अधिक तेजी से पकड़ा जा सकता है
• test code को simple रखें
  • test suite कोई ऐसी जगह नहीं है जहां जटिल refactoring या DRY(Don't Repeat Yourself) principle पर ज़ोर दिया जाए
  • समझने में आसान code लिखना महत्वपूर्ण है, और अतिरिक्त boilerplate code भी स्वीकार्य होना चाहिए
• tests को validate करें
  • test लिखते समय, अस्थायी रूप से expected result को उल्टा सेट करके test को फिर से चलाएं
  • सही तरीके से लिखा गया test इस स्थिति में fail होना चाहिए, जिससे test code की गलतियों को पहले ही रोका जा सके
• test failures को नज़रअंदाज़ न करें
  • चाहे test failure समझना कठिन हो या बहुत rare हो, फिर भी वह software के बारे में महत्वपूर्ण जानकारी देता है
  • debug करना कठिन failure cases अक्सर code की गंभीर खामियों को खोजने का अवसर बन सकते हैं
• determinism को अधिकतम करें
  • system की automatic processes को manually चलाने की mechanism बनाएं
  • उदाहरण: Raft snapshot feature सामान्यतः semi-automatic रूप से चलता है, लेकिन tests के दौरान इसे explicitly trigger करने योग्य बनाया गया है
• सजग रहें (Be Deliberate)
  • higher-level integration tests या E2E tests केवल तब जोड़ें जब उनकी आवश्यकता स्पष्ट रूप से साबित हो
  • अत्यधिक testing development और debugging की गति को कम कर सकती है
• apply करें और दोहराएं
  • performance tests में fsync calls को एक प्रमुख bottleneck के रूप में पहचाना गया, और Raft log entries को disk पर लिखने से पहले compress करके disk usage को optimize किया गया
• efficiency को महत्व दें
  • ऐसा test suite बनाए रखें जो कुछ मिनटों में चल सके, ताकि तेज़ iterative development संभव हो
  • यह open source project को maintain और active रखने के लिए एक महत्वपूर्ण लाभ है

quality पहले

• test pyramid का पालन करते हुए, हर test layer को स्पष्ट उद्देश्य के साथ design किया गया है
• distributed systems की complexity बढ़ने के साथ testing की simplicity बनाए रखना महत्वपूर्ण है
• लक्ष्य एक ऐसा database बनाना है जो reliable हो और operate करने में आसान हो

[GN⁺]

Hacker News टिप्पणी

• पहला टेस्ट सबसे कठिन होता है, लेकिन उसे जोड़ना फायदेमंद है। उसके बाद के टेस्ट आसान हो जाते हैं

  • पैरामीटराइज़्ड टेस्ट दोहराए जाने वाले कोड को कम करते हैं और तरह-तरह के टेस्ट संभव बनाते हैं
  • जब constraints का गहराई से सत्यापन किया जा सकता हो, तब यह उपयोगी होता है
  • Prop टेस्ट consistency और invariants की जांच में मदद करते हैं
  • यह सुनिश्चित करने के लिए mutation testing का इस्तेमाल करना महत्वपूर्ण है कि टेस्ट वाकई कुछ टेस्ट कर रहे हैं

• प्रोजेक्ट के प्रति समर्पण प्रभावशाली है

• टेस्ट पिरामिड समझ में आता है, लेकिन अक्सर सभी लेवल मौजूद नहीं होते, इसलिए इसे जल्दी सुधारने की स्थिति बन जाती है

  • कई टीमों के साथ काम करने पर e2e layer को भरना ऐसा काम बन जाता है जिसकी जिम्मेदारी कोई नहीं लेता
  • Auth0 जैसे authentication mechanism का उपयोग करने पर टेस्ट करना मुश्किल हो जाता है
  • e2e टेस्ट न हों तो सिस्टम आसानी से टूट सकता है
  • ऑटोमेटेड e2e टेस्ट समस्याओं की पहचान करना और rollback करना आसान बना देते हैं

• लगता है FAQ में copy-paste की गलती है

• Jepsen रिपोर्ट का इंतजार है

• वीडियो फ़ॉर्मैट में भी अच्छा लगा

• performance test setup से ईर्ष्या हो रही है

• rqlite इस्तेमाल करके देखा है, और यह अपनी सादगी को अच्छी तरह दिखाता है

• deterministic simulation testing पर राय पूछी जा रही है

• यह जानने की जिज्ञासा है कि rqlite का इस्तेमाल production environment में होता है या नहीं

• rqlite एक मौलिक और प्रतिभाशाली प्रोजेक्ट है