परीक्षण के लिए खराब फ़ाइल कैसे बनाएँ

आम तरीका

हाथ से बिगाड़ी गई फ़ाइल खराब टेस्ट क्यों है

आम तरीके हैं हेक्स एडिटर, कुछ यादृच्छिक बाइट पलटने वाली स्क्रिप्ट, या head अथवा truncate से फ़ाइल को छोटा काट देना। ये एक बार चलते हैं, फिर महँगे पड़ते हैं:

• हर बार अलग होता है। यादृच्छिक बाइट हर रन में नई जगह पड़ता है, इसलिए मंगलवार की विफलता बुधवार को लौटे, यह ज़रूरी नहीं।
• यह आकार बदल देता है। कटी हुई फ़ाइल उस सीमा से छोटी होती है जिसके नीचे उसे रहना था, इसलिए आकार की जाँच सामग्री की जाँच से पहले जवाब दे देती है और टेस्ट गलत कारण से पास हो जाता है।
• यह अक्सर किसी की नज़र में नहीं आता। सादा पाठ बीच में एक बाइट बदलने पर भी पढ़ा जाता है, और उदार इमेज रीडर उसे बस बना देता है, इसलिए जो फ़ाइल खराब होनी थी वह स्वीकार हो जाती है।
• यह नहीं बताता कि क्या होना चाहिए। फ़ाइल सिर्फ़ बाइट है, और जो बाद में टेस्ट पढ़ेगा उसे अंदाज़ा लगाना पड़ेगा कि इरादा स्वीकार करने का था या अस्वीकार करने का।

आपको क्या मिलता है

खराब फ़ाइल का आकार वही रहता है जो आपने माँगा था

फ़ाइल सामान्य रूप से बनती है और बाद में, डिस्क तक जाते समय, बिगाड़ी जाती है। वह माँगा हुआ आकार बनाए रखती है, और वही कमांड फिर वही बाइट लिखता है।

tfg generate --format png --size 2mb --damage zero-head --out ./out
tfg generate --format pdf --size 1mb --count 5 --damage zero-head:bytes=16 --out ./broken

सेटिंग कोलन के बाद लिखी जाती है। विकल्प दोहराया जा सकता है, और बिगाड़ आपके लिखे क्रम में लागू होते हैं। यह सभी 26 फ़ॉर्मैट के साथ चलता है।

यह क्या कर सकता है

कौन-कौन से बिगाड़ हैं?

यह वह सूची है जो प्रोग्राम छापता है, इस पेज को बनाते समय उसी से पढ़ी गई। tfg damage यही सूची छापता है, और tfg damage <id> बताता है कि उनमें से एक क्या लेता है।

zero-head फ़ाइल की शुरुआत पर शून्य लिख देता है। ज़्यादातर रीडर सबसे पहले वहीं देखते हैं, उस सिग्नेचर और हेडर पर जो बताते हैं कि फ़ाइल क्या है, इसलिए लगभग हर रीडर इसे भाँप लेता है। सादे पाठ और लॉग में सिग्नेचर नहीं होता और वे भी अस्वीकार होते हैं, क्योंकि शून्य बाइट की कतार पाठ नहीं है। चार बाइट से नीचे कुछ फ़ॉर्मैट ऐसे बिगाड़ के साथ निकलते हैं जिसकी कोई रीडर शिकायत नहीं करता, इसीलिए सेटिंग चार से शुरू होती है।

मैनिफ़ेस्ट क्या कहता है

एक मैनिफ़ेस्ट जो बताता है कि क्या होना चाहिए

हर खराब फ़ाइल को एक प्रविष्टि मिलती है जो कहती है कि आपके सिस्टम को उसे अस्वीकार करना चाहिए, और बिगाड़ उसके बगल में दर्ज रहता है:

"expected": {
  "outcome": "reject",
  "reason": "content_malformed",
  "confidence": "certain"
},
"damage": [
  {
    "type": "zero-head",
    "settings": {
      "bytes": "8"
    }
  }
]

दो अनुरोध कुछ भी लिखे जाने से पहले ठुकरा दिए जाते हैं, क्योंकि हर एक डिस्क पर ऐसी फ़ाइल छोड़ देता जिसका मैनिफ़ेस्ट गलत वर्णन करता:

• बिगाड़ को जितना चाहिए उससे छोटी फ़ाइल, जो ज्यों की त्यों निकलती
• बिगाड़ के साथ expected: accept, क्योंकि कोई भी उसे पूरा नहीं कर सकता। अगर आपके सिस्टम को फ़ाइल सुधारनी है तो sanitize लिखें, या अगर आप यही सवाल पूछ रहे हैं तो unspecified

रेसिपी में

एक रन में स्वस्थ और खराब फ़ाइलें

दोनों को एक रेसिपी में रखें, और मैनिफ़ेस्ट हर फ़ाइल की अपेक्षा साथ रखता है, इसलिए टेस्ट को यह बताने वाली सूची नहीं चाहिए कि कौन-सी कौन-सी है:

version: 1
targets:
  - id: healthy
    format: pdf
    size: 1mb
    expected: accept
  - id: broken
    format: pdf
    size: 1mb
    damage:
      - zero-head

टेस्ट में

इसे टेस्ट बनाना

टेस्ट मैनिफ़ेस्ट पढ़ता है और जाँचता है कि जो हुआ वही है जो घोषित किया गया था। उसे फ़ाइल नामों की सूची नहीं चाहिए:

import json, os

directory = "healthy-and-broken"
manifest = json.load(open(os.path.join(directory, "manifest.json")))

for entry in manifest["files"]:
    response = upload(os.path.join(directory, entry["path"]))
    if entry["expected"]["outcome"] == "reject":
        assert not response.ok
    else:
        assert response.ok

अच्छा इनकार साफ़ इनकार होता है। जो संदेश बताए कि क्या गलत था, वही वह जवाब है जो आप चाहते हैं। सर्वर त्रुटि, अटक जाना या आधी सहेजी फ़ाइल वह खराबी है जिसे ढूँढ़ने के लिए यह टेस्ट है।

आगे

यहाँ से कहाँ जाएँ

• upload-validation प्रीसेट किसी फ़ॉर्म से बाकी दो सवाल पूछता है, आकार का और प्रकार का।
• CI में टेस्ट फ़ाइलें ऐसी रेसिपी को पाइपलाइन में चलाती हैं।
• दस्तावेज़ में tfg generate का हर विकल्प है।