लोग इसका इस्तेमाल किसलिए करते हैं

अपलोड सीमाएँ

यह जाँचना कि फ़ाइल आकार सीमा वहीं लागू होती है जहाँ वह कहती है

एक सीमा एक नहीं, तीन टेस्ट केस है: ठीक नीचे, ठीक पर, और ठीक ऊपर। इन्हें हाथ से बनाने का मतलब बाइट संख्या निकालना और उम्मीद करना है कि आप एक से नहीं चूके। इसके बजाय सेट माँगें:

tfg generate --preset size-boundaries --limit 1mb --spread 1B --format pdf --out ./edges

आपको 1048575, 1048576 और 1048577 बाइट की तीन असली PDF मिलती हैं, और एक मैनिफ़ेस्ट जो कहता है कि पहली दो स्वीकार होनी चाहिए और तीसरी size_limit के कारण अस्वीकार। आपका टेस्ट तीन असर्शन हाथ से लिखने के बजाय अपेक्षा पढ़ता है - और जब सीमा बदलती है तो आप एक संख्या बदलकर दोबारा चलाते हैं।

जब आप इनलाइन एक ही सीमा सेट चाहें तो यही प्रीसेट के बिना भी चलता है:

tfg generate --format png --boundary 5mb --out ./png-edges

सतत एकीकरण

फ़िक्स्चर को खोए बिना रिपॉज़िटरी से बाहर रखना

बड़े बाइनरी फ़िक्स्चर रिपॉज़िटरी क्लोन करना धीमा और रिव्यू करना कठिन बनाते हैं, और किसी एक के बदले जाने पर कोई नहीं बता सकता कि क्या बदला। रेसिपी कुछ सौ अक्षरों की YAML है जो वही फ़ाइलें दोबारा बना देती है - किसी भी मशीन पर बाइट-दर-बाइट - क्योंकि हर फ़ाइल रन के सीड से निकलती है।

- name: build the fixtures
  run: tfg generate fixtures.yaml --out ./fixtures

- name: run the tests
  run: pytest tests/

- name: nothing moved
  run: tfg verify ./fixtures/manifest.json

हर अंत का अपना एग्ज़िट कोड है, इसलिए पाइपलाइन खराब रेसिपी, भरी डिस्क और सत्यापन असंगति में अंतर कर सकती है। विफल रन स्टैंडर्ड आउटपुट पर कुछ नहीं छापता, जिससे लॉग पार्सर किसी त्रुटि को डेटा नहीं पढ़ता।

पैमाना

यह जानना कि फ़ोल्डर बड़ा होने पर क्या होता है

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

tfg generate --format log --size-range 1kb-8kb --count 10000 --out ./fixtures

कुछ भी लिखे जाने से पहले देखें कि रन की क़ीमत क्या होगी, जो तब मायने रखता है जब कुल गीगाबाइट में नापा जाए:

tfg generate --format log --size-range 1kb-8kb --count 10000 --dry-run

डिस्क की खाली जगह से बड़ा रन पहला बाइट लिखे जाने से पहले ठुकरा दिया जाता है, डिस्क भरकर बीच में विफल होने के बजाय।

आर्काइव

ऐसे आर्काइव से अनपैकर का परीक्षण जिसमें सच में फ़ाइलें हैं

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

targets:
  - id: bundle
    format: zip
    contains:
      - format: txt
        count: 200
        size: 4kb

नेस्टिंग की गहराई, प्रविष्टियों की संख्या और अंदर की चीज़ों का आकार, ये सब वे बातें हैं जिन पर इंपोर्ट रूटीन की अपनी राय होती है, और इसी तरह आप जानते हैं कि वह राय क्या है।

पार्सर और व्यूअर

यह जाँचना कि आपका अपना कोड फ़ॉर्मैट को असली सॉफ़्टवेयर की तरह पढ़ता है

यहाँ का हर फ़ॉर्मैट भेजे जाने से पहले स्वतंत्र रीडर से जाँचा जाता है - PNG खोली जाती है और उसके पिक्सेल मिलाए जाते हैं, DOCX अलग लाइब्रेरी से वापस पढ़ा जाता है, आर्काइव खोला जाता है। इसका मतलब है कि जो फ़ाइल आपका पार्सर ठुकराता है वह आपके पार्सर के बारे में एक खोज है, जनरेटर के बारे में नहीं।

tfg generate --format docx --size 300kb --set paragraphs=120 --out ./documents
tfg generate --format xlsx --size 2mb --set rows=400 --set columns=6 --out ./sheets

फ़ॉर्मैट पेज हर एक की स्वीकार की जाने वाली सेटिंग और हर एक की सबसे छोटी संभव फ़ाइल सूचीबद्ध करता है।

गाइड

इनमें से दो, विस्तार से

• खराब टेस्ट फ़ाइलें - जानबूझकर बिगाड़ी गई, ठीक-ठीक आकार की फ़ाइल, जिसके साथ क्या होना चाहिए वह मैनिफ़ेस्ट में लिखा है।
• CI में टेस्ट फ़ाइलें - GitHub Actions का वर्कफ़्लो, GitLab का जॉब और वे एग्ज़िट कोड जो बिल्ड को विफल करते हैं।

यह किसके लिए है

QA इंजीनियर, टेस्ट ऑटोमेशन और हर वह व्यक्ति जिसके कोड के पीछे अपलोड फ़ॉर्म, इंपोर्ट रूटीन, पार्सर या स्टोरेज कोटा है। यह बिना किसी नेटवर्क की मशीन पर चलता है, जो बंद कॉर्पोरेट माहौल में मायने रखता है जहाँ ब्राउज़र आधारित जनरेटर विकल्प नहीं होता।

मुफ़्त और ओपन सोर्स, GPL-3.0। साइन अप की ज़रूरत नहीं। Windows और macOS के डाउनलोड हस्ताक्षरित हैं और बिना चेतावनी के शुरू होते हैं।