Birim testlerimizi düzenlemenin en iyi yolu nedir

Yıllar boyunca ana programımız için önemli sayıda birim test yaptık. Birkaç bin. Sorun şu ki, hangi testlerimiz olduğu konusunda net bir fikrimiz yok çünkü çok fazla var. Ve bu bir problem çünkü testlerde nerede zayıf olduğumuzu (veya kopyalarımız nerede) bilmiyoruz.

Bizim app bir raporlama motorudur. Böylece, ayrıştırmayı test etmek (tüm tablo özelliklerini okuyor muyuz), verilerde birleştirme (birleştirme işleminde doğru tablo özelliklerini tuttuk mu?), Son sayfayı biçimlendiren (tablo sayfaya doğru yerleştirilmiş bir şablona sahip olabilirsiniz) ) ve / veya çıktı biçimidir (oluşturulan DOCX dosyası doğrudur).

Buna test etmemiz gerekenleri de ekleyin. Dolguyu bir tablo hücresinin etrafında alın (rapor tasarımı için Word, Excel ve PowerPoint kullanıyoruz). Dolguyu sayfa sonu boyunca, bir hücrenin içindeki bir tablo, dikey olarak birleştirilmiş hücreler, yatay olarak birleştirilmiş hücreler, iç tabloda dikey ve yatay olarak birleştirilmiş hücreler içeren bir tablo içeren dikey ve yatay olarak birleştirilmiş bir hücre için test etmeliyiz. sayfa boyunca kesiliyor.

Peki bu test hangi kategoriye giriyor? Tablo doldurma, sayfa sonları, iç içe hücreler, dikey olarak birleştirilmiş hücreler, yatay olarak birleştirilmiş hücreler veya başka bir şey?

Ve bu kategorileri nasıl belgeliyoruz, birim testlerini adlandırıyoruz, vb.

Güncelleme: Birkaç kişi, tam kapsama sahip olduğumuzu doğrulamak için kapsam araçlarını kullanmanızı önerdi. Ne yazık ki bu bizim durumumuzda sınırlı kullanımdır çünkü hatalar belirli kombinasyonlardan kaynaklanma eğilimindedir, bu yüzden hepsi test edilmiş olan koddur, ancak bu kombinasyonda değil.

Örneğin, dün şablonlarında (Word belgesi) forEach döngüsünün sonunda bir Word yer işareti başlatan ve bir sonraki forEach döngüsünün başında sona eren bir müşterimiz vardı. Tüm bunlar kod üzerinde birim testleri olan kodu kullandı, ancak bir yer imini genişleten bir şablonun 25 kez başlatılmaya başlanıp 10 kez sona erdiğini düşünmemiştik (her iki forEop döngüsünde farklı sayıda satır vardı).

Genellikle, birim testleri için kaynak ağacı yansıtma eğilimindeyim. Yani, src / lib / fubar olsaydı, fubar için birim testleri içeren bir test / lib / fubar olurdu.

Ancak, tanımladığınız şey daha işlevsel testlerdir. Bu durumda, tüm olası koşullarınızı listeleyen çok boyutlu bir masam olurdu. Daha sonra, testi olmayanlar ya saçma ya da yeni bir teste ihtiyaç duyarlar. Elbette, bunları test süitleri setlerine koyabilirsiniz.

En yaygın yapı srcve testdizin aynası gibi görünüyor .

src/module/class
test/module/class_test

Ancak gördüğüm, şimdi daha iyi olduğuna inandığım alternatif bir yapı var.

src/module/class
src/module/class_test

Birim testi, test ettikleri sınıfı yansıtma eğiliminde olduğundan, bunları aynı dizine yerleştirmek, dosyalara çok daha kolay erişim sağlar, böylece her ikisinde de yan yana çalışabilirsiniz.

.NET'te, "Tests.Unit" veya "Tests.Integration" ana ad alanının altındaki test projelerinde kaynak kodun ad alanı yapısını yansıtma veya en azından yaklaşık olarak yansıtma eğilimindeyim. Tüm birim testleri tek bir projeye girer ve kaynak kodun temel yapısı proje içinde klasörler olarak çoğaltılır. Entegrasyon testleri için aynıdır. Yani, bir proje için basit bir çözüm şöyle görünebilir:

Solution
   MyProduct.Project1 (Project)
      Folder1 (Folder)
         ClassAA (Class def)
         ...
      Folder2
         ClassAB
         ...
      ClassAC
      ...
   MyProduct.Project2
      Folder1
         ClassBA
         ...
      ClassBB
      ...
   ...
   MyProduct.Tests.Unit
      Project1
         Folder1
            ClassAATests
            ClassAATests2 (possibly a different fixture setup)
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests
      ...
   MyProduct.Tests.Integration
      Project1 (a folder named similarly to the project)
         Folder1 (replicate the folders/namespaces for that project beneath)
            ClassAATests
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests

Birim sınama çerçevesiyle kodlanan tüm AAT'ler veya AEET'ler için bu biraz değişir; bu testler genellikle yeni bir kullanım senaryosunun veya hikayesinin işlevselliğini test edecek bir dizi adımı yansıtır. Bu testleri genellikle bir MyProduct.Tests.Acceptanceprojede, muhtemelen her aşama için yapılan testlerle, muhtemelen kilometre taşına veya geliştirilmekte olan hikayenin ait olduğu “destansı” hikayeye göre yapılandırıyorum . Ancak, bunlar gerçekten sadece uber entegrasyon testleridir ve bu yüzden testleri hikaye odaklı bir şekilde yerine daha nesne odaklı bir şekilde yapılandırmayı tercih ederseniz, bir MyProduct.Tests.Acceptanceveya benzer bir projeye bile ihtiyacınız yoktur ; sadece MyProduct.Tests.Integrationtest edilen en üst düzey nesnenin kapsamına atın .

Birim testinin sadece bir kategoride olması için bir neden yoktur. Tüm büyük birim test araç takımları , belirli bir kategori için testleri paketleyen test paketlerinin oluşturulmasını destekler . Belirli bir kod alanı değiştirildiğinde, geliştirici neyi bozduğunu görmek için önce bu paketi çalıştırmalıdır. Bir test dolgu ile ilgili olduğunda ve kırılma ve yuvalama ile , bunu her üç süite de koyun.

Bununla birlikte, birim testlerin noktası onları her zaman çalıştırmaktır, yani onları çalıştırmak için mümkün olan kadar küçük ve hızlı olmalıdırlar. tüm herhangi bir kod işlemekle befor. Başka bir deyişle, bir testin hangi kategoride olduğu önemli değildir, yine de taahhütte bulunmadan önce çalıştırılmalıdır. Suites gerçekten sadece herhangi bir nedenle olması gerektiği kadar hızlı testleri yazamıyorsanız kullanmanız gereken bir koltuk değneği vardır.

Kapsama gelince, testlerinizi yaparak hatların yüzde kaçının gerçekte kullanıldığını söyleyen çok iyi kapsama araçları vardır - bu, hala ne tür testlerin eksik olduğuna dair açık bir işarettir.

İsimlendirmeye gelince , birim testlerin isimleri için çaba harcamada belirli bir değer yoktur . Testlerinizden duymak istediğiniz her şey "5235 testin 5235'i geçti". Bir test başarısız olduğunda, ne okumak onun adı değil, ama mesajı örn dize, assert()o uygular başarı critrion. Mesaj, testin gövdesini okumadan neyin yanlış olduğu hakkında bir fikriniz olacak kadar bilgilendirici olmalıdır. Adı buna kıyasla önemsizdir.

Testlerde zayıf olup olmadığınızı bilmenin bir yolu izlenebilirliktir. Genellikle testler için bu, kapsam biçimini alır.

Amaç, testlerinizin hangi bölümlerinin uygulandığını ölçmektir, böylece testlerinizin kapsamına girmeyen kodu görebilirsiniz. Bir "kod parçası" nın ne olduğunu tanımlamak size (ve kapsam aracına) bağlıdır. En azı şube kapsamıdır.