Test için bozuk dosya nasıl yapılır

Olağan yol

Elle bozulmuş bir dosya neden kötü bir testtir

Olağan yollar bir onaltılık düzenleyici, birkaç rastgele baytı çeviren bir betik ya da bir dosyayı head veya truncate ile kısaltmaktır. Bir kez işe yarar, sonra size pahalıya mal olur:

• Her seferinde farklıdır. Rastgele bir bayt her çalıştırmada başka bir yere düşer, bu yüzden salı günkü bir hata çarşamba dönmeyebilir.
• Boyutu değiştirir. Kesilmiş bir dosya, altında kalması gereken sınırdan küçüktür. Böylece boyut denetimi içerik denetiminden önce yanıt verir ve test yanlış nedenle geçer.
• Çoğu zaman fark edilmez. Düz metin ortasında değişmiş bir baytla da okunur, hoşgörülü bir görüntü okuyucusu ise onu olduğu gibi çizer. Böylece bozuk olması gereken dosya kabul edilir.
• Ne olması gerektiğini söylemez. Dosya yalnızca bayttır ve testi sonradan okuyan, kabulün mü reddin mi amaçlandığını tahmin etmek zorunda kalır.

Ne elde edersiniz

Hasarlı bir dosya yine istediğiniz boyuttadır

Dosya normal üretilir, sonra diske giderken bozulur. İstediğiniz boyutu korur ve aynı komut yine aynı baytları yazar.

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

Ayarlar iki noktadan sonra yazılır. Seçenek tekrarlanabilir ve hasarlar yazdığınız sırayla uygulanır. 26 biçimin her biriyle çalışır.

Neler yapabilir

Hangi hasarlar var?

Bu, programın yazdırdığı listedir ve bu sayfa oluşturulurken programdan okunur. tfg damage aynısını yazdırır, tfg damage <id> ise birinin neyi kabul ettiğini söyler.

zero-head dosyanın başına sıfırlar yazar. Okuyucuların çoğu önce oraya bakar, dosyanın ne olduğunu söyleyen imzaya ve başlığa, bu yüzden hemen her okuyucu fark eder. Düz metin ve günlüklerin imzası yoktur ve onlar da reddedilir, çünkü bir sıfır baytı dizisi metin değildir. Dört baytın altında bazı biçimler hiçbir okuyucunun şikâyet etmediği bir hasarla çıkar, ayarın dörtten başlamasının nedeni budur.

Bildirim ne söyler

Ne olması gerektiğini söyleyen bir bildirim

Hasarlı her dosya, sisteminizin onu reddetmesi gerektiğini söyleyen bir kayıt alır ve hasar yanına yazılır:

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

İki istek, bir şey yazılmadan önce reddedilir, çünkü her biri diskte bildirimin yanlış tarif ettiği bir dosya bırakırdı:

• hasarın gerektirdiğinden küçük bir dosya, ki değişmeden çıkardı
• Bir hasarın yanında expected: accept, çünkü hiçbir şey bunu karşılayamaz. Sisteminiz dosyayı onarmalıysa sanitize, tam da bunu soruyorsanız unspecified yazın

Bir tarifte

Tek çalıştırmada sağlam ve bozuk dosyalar

İkisini de tek bir tarife koyun, bildirim her dosyanın beklentisini taşır. Böylece testin hangisinin hangisi olduğuna dair bir listeye ihtiyacı kalmaz:

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

Bir testte

Bunu bir teste dönüştürmek

Test bildirimi okur ve olanın bildirilenle aynı olup olmadığına bakar. Dosya adı listesine ihtiyacı yoktur:

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

İyi bir ret temiz bir rettir. Neyin yanlış olduğunu söyleyen bir ileti istediğiniz yanıttır. Sunucu hatası, takılma ya da yarım kaydedilmiş dosya, bu testin bulmak için var olduğu kusurdur.

Sonraki

Buradan nereye gidilir

• upload-validation hazır ayarı bir forma diğer iki soruyu sorar, boyutu ve türü.
• CI'da test dosyaları böyle bir tarifi bir hatta çalıştırır.
• Belgeler tfg generate için her seçeneği içerir.