Birim testinde “birim” altında neler anlaşılır?

Teoride "birim" altında anladığım kadarıyla insanlar yöntem (OOP). Ancak, bazı yöntemleri izole olarak doğrulayan uygulama testlerinde çok kırılgan davranış testleri vardır (sonucu değil, bazı bağımlılık yöntemlerinin çağrıldığını doğrulamak). Bu yüzden, üniteye göre küçük bir grup yakından ilgili sınıfı anlayan birçok insan görüyorum. Bu durumda sadece dış bağımlılıklar alay edilir / kesilir ve birim içindeki bağımlılıklar için gerçek uygulamalar kullanılır. Bu durumda daha fazla durum, anlamlı (spesifikasyona göre) vardır ve çok kırılgan testler yoktur. Soru şu; bu yaklaşımlar hakkında nasıl hissediyorsunuz ve ikinci yaklaşım birimi testi olarak adlandırmak geçerli mi yoksa bir çeşit düşük seviyeli entegrasyon testi olabilir mi?

TDD'nin bu test yöntemlerinden biriyle uygulanmasıyla ilgili bazı özel hususlar görürseniz, düşünceleriniz için teşekkür ederim.

Başlangıçta TDD, test kodunda şimdi iyi tanımlanmış olan spesifikasyon göz önüne alındığında, kodladığınız şeyin doğru kalmasını sağlamak için testin önceden yazıldığı çevik hareketten geldi. Ayrıca, kodunuzu değiştirdiğinizde, kodun davranışını değiştirmediğinizi kanıtlamak için testlere güvenebileceğinizden, yeniden düzenlemenin çok önemli bir yönü olarak ortaya çıktı.

Daha sonra insanlar geldi ve kodunuz hakkında bilgi sahibi olduklarını düşündükleri ve daha sonra birim testlerinizi yazmanıza yardımcı olmak için test saplamaları oluşturabileceklerini düşündüler ve bence her şey yanlış gitti.

Test saplamaları, ne yaptığına dair hiçbir fikri olmayan bir bilgisayar tarafından üretilir, sadece her yöntem için dikkatsizce bir saplama üretir, çünkü bunu yapması söylenir. Bu, söz konusu yöntemin karmaşıklığından veya tek başına test için uygun olup olmadığından bağımsız olarak her yöntem için bir test durumunuz olduğu anlamına gelir.

Bu, TDD metodolojisinin yanlış ucundan teste geliyor. TDD'de kodun ne yapacağını bulmanız ve ardından bunu başaran bir kod üretmeniz gerekir. Bu, kodun kodun ne yapması gerektiğini yaptığını kanıtlayan testler yazmanız gerektiği için kendini gerçekleştirir. Yöntem tabanlı test saplamalarının otomatik oluşturulmasıyla birlikte, kodunuzun her küçük yönünü kanıtlayarak zamanınızı boşa harcarsınız, bu da tüm küçük parçalar bir araya getirildiğinde kolayca yanlış olduğunu kanıtlayabilir.

Fowler kitabında testi tarif ettiğinde, her sınıfı kendi ana yöntemiyle test etmeye atıfta bulundu. Bunu geliştirdi, ancak konsept hala aynı - tüm sınıfı test edersiniz, böylece bir bütün olarak çalışır, tüm bu yöntemlerin etkileşimini kanıtlamak için tüm testleriniz bir araya getirilir, böylece sınıf tanımlanan beklentilerle tekrar kullanılabilir.

Test araç kitleri bize bir kötülük yaptı, araç setinin gerçekten bir şeyler yapmanın tek yolu olduğunu düşünme yolunu açtı, kodunuzdan en iyi sonucu almak için kendiniz için daha fazla düşünmeniz gerekiyor. Küçük kodlar için test kodlarına körü körüne koymak, sadece bir entegrasyon testinde çalışmanızı tekrarlamanız gerektiği anlamına gelir (ve bunu yapacaksanız, şimdi yedekli ünite test aşamasını tamamen atlamıyorsunuz). Ayrıca, insanların% 100 test kapsamı almaya çalışırken çok fazla zaman harcadıkları ve kodun entegrasyon testini daha kolay hale getirmesi için daha iyi harcanan büyük miktarda alaycı kod ve veri oluşturduğu anlamına gelir (yani, çok fazla veri bağımlılıkları, birim testi en iyi seçenek olmayabilir)

Son olarak, yönteme dayalı birim testlerinin kırılganlığı sorunu ortaya koymaktadır. Yeniden düzenleme, birim testlerle birlikte kullanılmak üzere tasarlanmıştır, eğer testleriniz her zaman kırılırsa, yeniden düzenleme yaptığınız için bir şey tüm yaklaşımda ciddi bir şekilde ters gitti. Yeniden düzenleme yöntemleri oluşturmayı ve silmeyi sever, bu yüzden açıkçası yöntem başına kör test yaklaşımı başlangıçta amaçlanan değildir.

Birçok yöntemin onlar için testler alacağından şüphem yok, bir sınıfın tüm genel yöntemlerinin test edilmesi gerekir, ancak bunları tek bir test vakasının parçası olarak birlikte test etme konseptinden uzaklaşamazsınız. Örneğin, bir set ve get yöntemim varsa, verileri içine alan testler yazabilir ve dahili üyelerin uygun olup olmadığını kontrol edebilirim, ya da her birini bazı verileri koymak ve sonra tekrar alıp almadığımı görmek için kullanabilirim hala aynı ve bozuk değil. Bu sınıfı test ediyor, her yöntem izole değil. Ayarlayıcı yardımcı bir özel yönteme dayanıyorsa, sorun değil - tüm sınıfı test ediyorsanız ayarlayıcının çalıştığından emin olmak için özel yöntemi taklit etmeniz gerekmez.

Bence din bu konuya giriyor, dolayısıyla şimdi 'davranış güdümlü' ve 'test güdümlü' gelişme olarak bilinen şemaya bakıyorsunuz - birim testin orijinal konsepti davranış güdümlü gelişim içindi.

Bir birim en yaygın olarak "uygulamanın en küçük test edilebilir kısmı " olarak tanımlanır . Çoğu zaman, evet, bu bir yöntem anlamına gelir. Ve evet, bu, bağımlı bir yöntemin sonucunu test etmemeniz gerektiği, ancak yöntemin çağrılması gerektiği anlamına gelir (ve sonra yalnızca bir kez, mümkünse, bu yöntem için her testte değil).

Buna kırılgan diyorsunuz. Bence bu yanlış. Kırılgan testler, ilgisiz koda yapılan en ufak bir değişiklik altında kırılan testlerdir. Yani, test edilen işlevsellikle alakasız olan koda dayananlar.

Bununla birlikte, gerçekten söylemek istediğinizi düşündüğüm, bağımlılığı olmayan bir yöntemi test etmenin kapsamlı olmadığıdır. Bu noktada katılıyorum. Ayrıca, uygulama yapmak için kod birimlerinin doğru bağlandığından emin olmak için entegrasyon testlerine ihtiyacınız vardır.

Bu tam olarak davranış odaklı gelişimin ve özellikle kabul-test odaklı gelişimin çözmek için ortaya koyduğu sorundur . Ancak bu, birim testleri / test odaklı geliştirme ihtiyacını ortadan kaldırmaz; sadece tamamlar.

Adından da anlaşılacağı gibi her testte bir atomik nesneyi test ediyorsunuz. Böyle bir konu genellikle tek bir yöntemdir. Birden fazla test aynı yöntemi, mutlu yolu, olası hataları, vb. Kapsayacak şekilde test edebilir. İç mekaniği değil, davranışı test ediyorsunuz. Dolayısıyla birim testi, bir sınıfın genel arabirimini, yani belirli bir yöntemi test etmekle ilgilidir.

Birim testinde, bir yöntemin tek başına, yani herhangi bir bağımlılığı saplayarak / alay ederek / taklit ederek test edilmesi gerekir. Aksi takdirde, 'gerçek' bağımlılıkları olan bir birimi test etmek bir entegrasyon testi yapar. Her iki test türü için de bir zaman ve yer vardır. Birim testleri, tek bir deneğin beklendiği gibi bağımsız çalışmasını sağlar. Entegrasyon testleri 'gerçek' konuların birlikte doğru çalışmasını sağlar.

Temel kuralım: Hataları içerecek kadar karmaşık olan en küçük kod birimi.

Bunun bir yöntem veya sınıf veya alt sistem olup olmadığı belirli koda bağlıdır, genel bir kural verilemez.

Örneğin, basit alıcı / ayarlayıcı yöntemlerini tek başına veya başka bir yöntemi çağıran sarma yöntemlerini test etmek için herhangi bir değer sağlamaz. Sınıfın yalnızca ince bir sargı veya adaptör olması durumunda bütün bir sınıfı bile test etmek çok kolay olabilir. Test edilecek tek şey, bir alayda bir yöntemin çağrılması ise, test edilen kodun incelmesi.

Diğer durumlarda, tek bir yöntem, tek başına test etmek için değerli olan karmaşık bir hesaplama yapabilir.

Birçok durumda, karmaşık bölümler bireysel sınıflar değil, sınıflar arasındaki bütünleşmedir. Böylece aynı anda iki veya daha fazla sınıfı test edersiniz. Bazıları bunun birim testler değil entegrasyon testleri olduğunu söyleyecek, ancak terminolojiye aldırmayacaklar: Karmaşıklığın nerede olduğunu test etmelisiniz ve bu testler test takımının bir parçası olmalıdır.