Cara membuat file rusak untuk pengujian

Cara yang biasa

Mengapa file yang dirusak dengan tangan adalah tes yang buruk

Cara yang biasa adalah editor hex, skrip yang membalik beberapa byte acak, atau memotong file dengan head atau truncate. Berhasil sekali, lalu merugikan Anda:

• Hasilnya berbeda setiap kali. Byte acak jatuh di tempat baru pada setiap proses, jadi kegagalan hari Selasa mungkin tidak muncul lagi hari Rabu.
• Ukurannya berubah. File yang dipotong lebih kecil daripada batas yang seharusnya tidak dilewatinya, sehingga pemeriksaan ukuran menjawab sebelum pemeriksaan isi dan tes lulus karena alasan yang salah.
• Sering tidak terdeteksi. Teks biasa masih terbaca dengan satu byte berubah di tengah, dan pembaca gambar yang toleran hanya menggambarnya, sehingga file yang seharusnya rusak malah diterima.
• Tidak mengatakan apa yang seharusnya terjadi. File hanyalah byte, dan siapa pun yang membaca tes itu kemudian harus menebak apakah yang dimaksud penerimaan atau penolakan.

Yang Anda dapatkan

File yang rusak tetap berukuran seperti yang Anda minta

File dibuat seperti biasa lalu dirusak, dalam perjalanan ke disk. Ukurannya tetap seperti yang Anda minta, dan perintah yang sama menulis byte yang sama lagi.

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

Pengaturan ditulis setelah titik dua. Opsi ini bisa diulang, dan kerusakan diterapkan menurut urutan yang Anda tulis. Berlaku untuk semua 26 format.

Yang bisa dilakukan

Kerusakan apa saja yang ada?

Ini daftar yang dicetak program, dibaca darinya saat halaman ini dibangun. tfg damage mencetak daftar yang sama, dan tfg damage <id> menjelaskan apa yang diterima salah satunya.

zero-head menulis nol di atas awal file. Sebagian besar pembaca melihat ke sana lebih dulu, ke tanda pengenal dan header yang menyatakan file itu apa, jadi hampir semua pembaca menyadarinya. Teks biasa dan log tidak punya tanda pengenal dan juga ditolak, karena deretan byte nol bukan teks. Di bawah empat byte, sebagian format keluar dengan kerusakan yang tidak dikeluhkan pembaca mana pun, itulah sebabnya pengaturan dimulai dari empat.

Yang dikatakan manifes

Manifes yang menyatakan apa yang harus terjadi

Setiap file yang rusak mendapat catatan yang menyatakan sistem Anda harus menolaknya, dengan kerusakannya dicatat di sampingnya:

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

Dua permintaan ditolak sebelum apa pun ditulis, karena masing-masing akan meninggalkan file di disk yang dijelaskan keliru oleh manifes:

• file yang lebih kecil dari yang dibutuhkan kerusakan, yang akan keluar tanpa perubahan
• expected: accept di samping kerusakan, karena tidak ada yang bisa memenuhinya. Tulis sanitize jika sistem Anda memang harus memperbaiki file itu, atau unspecified jika justru itu pertanyaan Anda

Dalam resep

File sehat dan rusak dalam satu proses

Taruh keduanya dalam satu resep, dan manifes membawa harapan setiap file, sehingga tes tidak butuh daftar mana yang mana:

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

Dalam tes

Menjadikannya tes

Tes membaca manifes dan memeriksa bahwa yang terjadi sama dengan yang dinyatakan. Tidak perlu daftar nama file:

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

Penolakan yang baik adalah penolakan yang bersih. Pesan yang menyebut apa yang salah adalah jawaban yang Anda inginkan. Kesalahan server, macet, atau file yang tersimpan setengah adalah cacat yang ingin ditemukan tes ini.

Berikutnya

Ke mana dari sini

• Preset upload-validation mengajukan dua pertanyaan lain kepada sebuah formulir, soal ukuran dan soal jenis.
• File uji di CI menjalankan resep seperti ini di pipeline.
• Dokumentasi memuat setiap opsi tfg generate.