คนใช้มันทำอะไร

ขีดจำกัดการอัปโหลด

ทดสอบว่าขีดจำกัดขนาดไฟล์ถูกบังคับใช้ตรงที่บอกไว้หรือไม่

ขีดจำกัดหนึ่งค่าคือกรณีทดสอบสามกรณี ไม่ใช่หนึ่ง: ต่ำกว่าเล็กน้อย ตรงพอดี และสูงกว่าเล็กน้อย การทำด้วยมือหมายถึงคำนวณจำนวนไบต์และหวังว่าจะไม่พลาดไปหนึ่ง ขอเป็นชุดแทน:

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

คุณได้ PDF จริงสามไฟล์ขนาด 1048575, 1048576 และ 1048577 ไบต์ พร้อมแมนิเฟสต์ที่บอกว่าสองไฟล์แรกควรถูกยอมรับและไฟล์ที่สามถูกปฏิเสธด้วย 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 ลงนามแล้วและเริ่มทำงานโดยไม่มีคำเตือน