Tüm birim testleri tek bir yürütülebilir dosyada mı yoksa bölünmüş mü?

Bir yazılım için testler yazarken, bir kütüphane diyelim, tüm birim testlerini bir tanede derlemeyi mi yoksa birkaç çalıştırılabilir dosyada mı ayırmayı tercih edersiniz?

Sormamın nedeni şu anda üzerinde çalıştığım bir kütüphaneyi test etmek için CUnit kullanıyorum . Testler, arızalar için basılı çıktı ile tamamlanmış tek bir yürütülebilir dosyaya derlenen ayrı süitlere bölünür. Şimdi, bu kütüphane için derleme sistemi , kendi test çerçevesi CTest ile birlikte gelen CMake (adına rağmen CUnit ile pek ilgisi yok) . CTest, test görevi gören yürütülebilir dosyaların bir listesini kaydetmeme izin veriyor.

CTest'in otomatik test çalışmaları için kullanılıp kullanılmayacağını merak ediyorum. Ancak bu, şimdiye kadar yazdığım testleri ayrı derleme hedeflerine ayırmamı gerektiriyordu. Aksi takdirde, testleri seçerek yürütmek gibi bazı CTests gelişmiş özelliklerini gerçekten kullanamıyorum.

Bunun daha çok hangi araçların kullanılması ve bunların kullanımı ve sözleşmeleri ile ilgili bir soru olduğunu fark ettim, ancak bunun dışında, tek bir test yürütülebilir dosyasını ayrı olanlara göre tercih etmenin başka nedenleri var mı? Ya da tam tersi?

Tek tek ikili dosyalarda otomatik testler yaptırmayı veya en azından "birbirine ait" grup başına kümelenmeyi ve sonra basit bir kabuk komut dosyasından (sıfır olmayan çıkış kodunun hata verdiğini ve stderr'deki çıkışın yakalanabileceğini) çağırmayı seviyorum bir açıklamayı kaydetmek için). Bu şekilde, testte tam esnekliği koruyorum - bireysel komutları doğrudan komut satırından çalıştırabilirim, istersem her türlü süslü komut dosyası yapabilirim, herhangi bir şeyi yeniden derlemeden uygun gördüğüm gibi onları yeniden sıralayabilirim.

Ama daha da önemlisi, aynı dilde farklı dillerde yazılmış veya farklı takım zincirleri kullanarak yapılan testleri dahil etmeme izin veriyor. Örneğin, yazdığım birim testleri büyük olasılıkla projenin ana dilinde yapılır ve bunları çalıştırmak ikili dosyaları oluşturmak ve çağırmaktır; ama ben de benim veritabanı test etmek istiyorum, ve ben bunun için SQL betikleri doğrudan veritabanına beslemek isteyebilirsiniz; (Sadece bir tür linter olsa bile) benim kod üzerinde bazı statik kod analiz aracı çalıştırmak isteyebilirsiniz. Statik HTML'imi bir geçerlilik denetleyicisi aracılığıyla çalıştırmak isteyebilirim. Ben grepşüpheli yapılar, kodlama tarzı ihlalleri veya "kırmızı bayrak" anahtar kelimeleri kontrol etmek için kod tabanı üzerinde bir komut çalıştırabilir . Olasılıklar sınırsızdır - komut satırından çalıştırılabilir ve "sıfır çıkış durumu TAMAM anlamına gelir" ise, onu kullanabilirim.

Bir uygulamanın birim testleri için (veya yaygın olarak paylaşılan bir kütüphane paketi için) bir kütüphaneye sahip olma eğilimindeyim. Bu kütüphane içinde, test fikstürleri için test edilen nesnelerin ad alanlarını çoğaltmaya veya yaklaşık olarak denemeye çalışıyorum (çoğunlukla NUnit kullanıyorum). Bu, derlemeyi kolaylaştırır, çünkü .NET'te, her bir ikili dosyayı oluştururken, aynı LOC ile 10 proje çözümünün 20 proje çözümünün inşa süresini artıracak bir genel gider vardır. Test ikili dosyaları yine de dağıtılmaz, bu nedenle testlerin herhangi bir ikili programa organizasyonu sizin rahatınız içindir ve genellikle YAGNI'nın burada her yerde geçerli olduğunu görüyorum.

Şimdi, genellikle tdammers'ın sahip olduğu düşüncelere sahip değilim; kodum neredeyse hepsi tek bir dilde ve SQL dizeleri içeren herhangi bir test bir birim testi değil (bir sorgu üreticisinin belirli kriterler göz önüne alındığında beklenen SQL dizesini döndürdüğünü test etmiyorsanız) ve gerçekte hiçbir zaman gerçekte birim testi yapmıyorum UI (birçok durumda imkansızdır). Ayrıca, yapı botları ve IDE eklentileri gibi üçüncü taraf araçlar tarafından iyi kabul edilen bir birim test kütüphanesi kullanıyorum ve bu nedenle bireysel testler, kısmi süitler vb.