वैलिडेशन टेस्ट जनरेटर — फ़ॉर्म और फ़ील्ड वैलिडेशन टेस्ट बनाएँ

वैलिडेशन टेस्ट जनरेटर कैसे इस्तेमाल करें

हर इनपुट को उसकी validation constraints के साथ, एक पंक्ति में एक, लिखें।
स्वाभाविक नाम इस्तेमाल करें (confirmPassword, startDate, endDate) ताकि cross-field नियम पहचाने जा सकें।
Generate दबाएँ और नियम तालिका को अपने specification से मिलाकर देखें।
केस अपने test management टूल में एक्सपोर्ट करें।

वैलिडेशन टेस्ट जनरेटर की खूबियाँ

required, फ़ॉर्मेट, टाइप, रेंज, लंबाई, आइटम-संख्या, फ़ाइल, pattern, अनुमत वैल्यू, कॉम्प्लेक्सिटी और uniqueness नियम पहचानता है
हर नियम के लिए एक पास होने वाला और एक फ़ेल होने वाला टेस्ट, अपेक्षित मैसेज के साथ
cross-field नियम: confirm password, confirm email, start/end तारीख़ का क्रम, बराबर-तारीख़ वाली boundary सहित
हर फ़ील्ड के लिए "सुधार के बाद एरर हट जाना" वाला usability केस
यह साबित करने वाला Critical केस कि सर्वर-साइड validation को बायपास नहीं किया जा सकता
नियम तालिका और क्रमांकित केस, जो Markdown, JSON, CSV या Gherkin में एक्सपोर्ट किए जा सकते हैं

वैलिडेशन टेस्ट जनरेटर का उदाहरण

password reset फ़ॉर्म के validation नियम

इनपुट:

password: password, required, min=10
confirmPassword: password, required

आउटपुट:

password   Required     ""              "Password is required"
password   Complexity   password        "Password is too weak"
password   Min length   9 chars         "Password must be at least 10 characters"
VAL-009    ConfirmPassword must match password → "Passwords do not match"
VAL-010    Server-side validation cannot be bypassed → API responds 400/422

वैलिडेशन टेस्ट जनरेटर के बारे में अक्सर पूछे जाने वाले सवाल

कौन-कौन से नियम पहचाने जाते हैं?

Required, टाइप/फ़ॉर्मेट (email, URL, phone, date, UUID), min/max वैल्यू, min/max लंबाई, आइटम संख्या, फ़ाइल साइज़ और टाइप, pattern, अनुमत वैल्यू, password कॉम्प्लेक्सिटी और uniqueness — हर एक के साथ एक पास होने वाला और एक फ़ेल होने वाला इनपुट तथा अपेक्षित मैसेज।

क्या cross-field नियम समर्थित हैं?

हाँ: confirmPassword का password से मेल खाना, end तारीख़ का start तारीख़ से पहले न होना (बराबर-तारीख़ वाली boundary के साथ), और confirmEmail का email से मेल खाना। फ़ील्ड के नाम स्वाभाविक रखें और नियम अपने आप पकड़ लिए जाएँगे।

सर्वर-साइड बायपास वाला केस क्यों है?

फ़्रंट-एंड validation बंद की जा सकती है। जनरेट हुआ Critical केस अमान्य डेटा सीधे API पर भेजता है और वहीं फ़ील्ड-स्तर के एरर की उम्मीद रखता है।

क्या मैं अपेक्षित मैसेज बदल सकता हूँ?

मैसेज एक तटस्थ परंपरा का पालन करते हैं ("Email is required")। एक्सपोर्ट की गई CSV या JSON में उन्हें अपने प्रोडक्ट की भाषा से बदल दें।