Aynı ağaçta 30,08 ms ve 10,31 ms: ölçmek düzeltmekten zor

Kodun ölçülebilir biçimde hiç değişmediği bir turda, aynı ağaçta üç ayrı ilk bayt havuzu koşuldu ve tek değişken makinenin yüküydü. Yük ortalaması 25,55 iken havuz medyanı 22,35 ms çıktı, ham okumalar 5,23 ile 67,09 arasında; yük 23 ve düşerken 30,08 ms, ham okumalar 5,92 ile 343,20 arasında ve tek bir alt koşu tek başına 89,28 medyan verdi; makine oturup yük 3,6 ile 4,8 arasına indiğinde 10,31 ms, ham okumalar 6,93 ile 24,58 arasında. Kural buradan çıktı: tek koşuluk sayılar birbiriyle kıyaslanmaz, havuzlanmış medyan ham aralığa karşı okunur. Aynı gürültü bir kez kapıyı da kırmızıya çevirdi, ama düşen şey bir iddia değil bir zaman aşımıydı; yük 42,9 iken kırmızı olan süit, makine 11,3'e indiğinde 293,87 saniye yerine 24,80 saniyede 2359 testin 2359'unu geçti.

Araçlar da yalan söyler

İkinci zorluk araçların yalan söylemesi, ve üçü de ölçüldü. pnpm --filter web test --run ve aynı komutun --exclude verilmiş hâli sessizce hiçbir şey koşmuyor ve sıfırla çıkıyor, yani süit yeşil diye okunuyor; ters yönde, iki filtre verilen bir pnpm vitest run hiç test dosyası bulamadığını söyleyip 1 ile çıkıyor, yani kırmızı diye okunuyor. Sonuç şu: mutasyon turlarında çıkış koduna değil logdaki geçen test sayısı satırına bakılır. İkincisi kabuğun kendisi, bir echo satırının içine bir komut ikamesi koymak son çıkış kodunu sıfırlıyor, çünkü ikame önce koşuyor; bir turun bütün çıkış kodları bu yüzden yanlış yazıldı ve gerçekten 1 ile çıkan bir prob kayda 0 olarak geçti. Üçüncüsü macOS'un bash 3.2 sürümü, ilişkisel dizi yok, kullanan mutasyon koşucusunun trap işlevi hiçbir dosyayı geri almadı ama geri aldığını yazdı; mutasyonlar ağaçta birikti ve bir atfı kirletti, yakalayan şey de bir test değil bir git status okuması oldu.