Testlerin test ettikleri kodla aynı satırda yazılmamasının bir nedeni var mı?

Son zamanlarda Literatür Programlama hakkında biraz okudum ve bana şunu düşündürdü ... İyi yazılmış testler, özellikle BDD tarzı özellikler, kodun dürtüsünden çok ne yaptığını açıklamak için daha iyi bir iş yapabilir. kendi doğruluğunu doğrulama.

Test ettikleri kodla aynı satırda yazılmış testleri hiç görmedim. Bunun nedeni, dillerin aynı kaynak dosyaya yazıldığında uygulama ve test kodunu ayırmayı basitleştirme eğiliminde olmamasıdır (ve kimse bunu kolaylaştırmaz), veya insanların test kodunu uygulama kodundan ayırmasının daha temel bir nedeni var mı?

Satır içi testler için düşünebildiğim tek avantaj, yazılacak dosya sayısını azaltmak olacaktır. Modern IDE'lerde bu gerçekten önemli bir şey değil.

Bununla birlikte, satır içi testlerde bariz dezavantajlar vardır:

• Endişelerin ayrılmasını ihlal ediyor . Bu tartışılabilir olabilir, ancak bana göre işlevselliği test etmek onu uygulamaktan farklı bir sorumluluktur.
• Testler / uygulama arasında ayrım yapmak için yeni dil özellikleri sunmak zorunda kalırsınız veya ikisi arasındaki çizgiyi bulanıklaştırma riskini alırsınız.
• Daha büyük kaynak dosyalarının çalışması daha zordur: okunması zor, anlaşılması zor, kaynak denetimi çakışmaları ile uğraşmanız daha olasıdır.
• Konuşmak için "tester" şapkanı takmanın daha zor olacağını düşünüyorum. Uygulama ayrıntılarına bakıyorsanız, belirli testleri uygulamayı atlamak için daha cazip olursunuz.

Bazılarını düşünebilirim:

• Okunabilirlik. "Gerçek" kodun serpiştirilmesi ve testler gerçek kodu okumayı zorlaştıracaktır.

• Kod şişirmek. "Gerçek" kod ve test kodunu aynı dosyalara / sınıflara / daha büyük derlenmiş dosyalara, vb. Neden olacak şekilde karıştırmak vb.

• Müşterilerinizin / müşterilerinizin test kodunuzu görmesini istemeyebilirsiniz. ( Bu nedenden hoşlanmıyorum ... ama kapalı kaynak kodlu bir proje üzerinde çalışıyorsanız, test kodunun müşteriye yardımcı olması pek mümkün değildir.)

Şimdi bu sorunların her biri için olası geçici çözümler var. Ancak IMO, ilk etapta oraya gitmemek daha kolaydır.

Java programcılarının ilk günlerde böyle şeyler yaptığını gözlemlemeye değer; örneğin main(...)testi kolaylaştırmak için bir sınıfa bir yöntem dahil etmek. Bu fikir neredeyse tamamen ortadan kalktı. Bir tür test çerçevesi kullanarak ayrı ayrı testler yapmak endüstri uygulamasıdır.

Ayrıca, Literatür Programlamanın (Knuth tarafından tasarlandığı gibi) yazılım mühendisliği endüstrisinde asla yakalanmadığını gözlemlemeye değer.

Aslında, Design By Contract'ı bunu yaptığınızı düşünebilirsiniz . Sorun çoğu programlama dilinin bu şekilde kod yazmanıza izin vermemesidir :( Önkoşulları elle test etmek çok kolaydır, ancak posta koşulları, kod yazma şeklinizi değiştirmeden gerçek bir sorundur (büyük bir negatif IMO).

Michael Feathers'ın bununla ilgili bir sunumu var ve bu, kod kalitesini geliştirebileceğinizden bahsettiğiniz yollardan biri.

Kodunuzdaki sınıflar arasında sıkı bağlantıdan kaçınmaya çalıştığınız birçok nedenden dolayı, testler ve kod arasında gereksiz bağlantıdan kaçınmak iyi bir fikirdir.

Oluşturma: Testler ve kod farklı zamanlarda farklı kişiler tarafından yazılabilir.

Kontrol: Gereksinimleri belirtmek için testler kullanılıyorsa, kesinlikle onları kimin değiştirebileceği ve gerçek kodun ne olduğu konusunda farklı kurallara tabi olmalarını istersiniz.

Yeniden kullanılabilirlik: Testleri satır içi yaparsanız, başka bir kod parçasıyla kullanamazsınız.

İşi doğru yapan bir kod parçasına sahip olduğunuzu, ancak performans, bakım, her neyse arzulanan çok şey bıraktığınızı hayal edin. Bu kodu yeni ve geliştirilmiş kodla değiştirmeye karar veriyorsunuz. Aynı test kümesini kullanmak, yeni kodun eski kodla aynı sonuçları verdiğini doğrulamanıza yardımcı olabilir.

Seçilebilirlik: Testleri koddan ayrı tutmak, hangi testleri yapmak istediğinizi seçmenizi kolaylaştırır.

Örneğin, yalnızca üzerinde çalışmakta olduğunuz kodla ilgili küçük bir test paketi ve tüm projeyi test eden daha büyük bir paketiniz olabilir.

İşte aklıma gelen bazı ek nedenler:

• ayrı bir kütüphanede testlere sahip olmak, sadece bu kütüphaneyi test çerçevenize bağlamayı ve üretim kodunuza bağlamayı kolaylaştırır (bazı önişlemcilerden kaçınılabilir, ancak neden daha kolay bir çözüm testleri yazmaksa ayrı bir yer)

• Bir fonksiyonun, bir sınıfın, bir kütüphanenin testleri genellikle "kullanıcılar" bakış açısıyla yazılır (bu fonksiyon / sınıf / kütüphanenin kullanıcısı). Böyle bir "kod kullanma" tipik olarak ayrı bir dosyaya veya kütüphaneye yazılır ve bu durumu taklit ederse bir test daha net veya "daha gerçekçi" olabilir.

Testler satır içi olsaydı, ürünü müşterinize gönderirken test etmek için gereken kodu kaldırmak gerekir. Dolayısıyla bunu testleri saklamak fazladan yer basitçe kodu arasında ayıran Eğer ihtiyaç ve kod müşteri ihtiyacı var.

Bu fikir, sadece nesne tabanlı veya nesne yönelimli bir tasarım bağlamında bir "Self_Test" yöntemine karşılık gelir. Ada gibi derlenmiş bir nesne tabanlı dil kullanılıyorsa, tüm otomatik test kodu derleyici tarafından üretim derlemesi sırasında kullanılmamış (hiç çağrılmadı) olarak işaretlenir ve bu nedenle hepsi en iyi duruma getirilir - hiçbiri ekranda görünmez sonuçta çalıştırılabilir.

Bir "Self_Test" yöntemi kullanmak son derece iyi bir fikirdir ve programcılar kaliteyle gerçekten ilgileniyorlarsa, hepsi bunu yapardı. Yine de önemli konulardan biri, "Self_Test" yönteminin, uygulama detaylarının hiçbirine erişememesi ve bunun yerine sadece nesnenin spesifikasyonunda yayınlanan tüm diğer metotlara dayanması gerektiği için yoğun bir disipline sahip olması gerektiğidir. Açıkçası, öz sınama başarısız olursa, uygulamanın değişmesi gerekecektir. Öz sınama, nesnenin yöntemlerinin tüm yayınlanmış özelliklerini titizlikle sınamalıdır, ancak hiçbir zaman belirli bir uygulamanın ayrıntılarına hiçbir zaman güvenmez.

Nesneye dayalı ve nesneye yönelik diller, test edilen nesnenin dışındaki yöntemlerle ilgili olarak tam olarak bu tür bir disiplin sağlarlar (nesnenin özelliklerini zorlarlar, uygulama ayrıntılarına erişimi engeller ve bu tür bir girişim tespit edilirse bir derleme hatası oluştururlar) ). Ancak, nesnenin kendi iç yöntemlerine tüm uygulama detaylarına tam erişim sağlanır. Bu yüzden öz sınama yöntemi benzersiz bir durumda: doğası nedeniyle bir iç yöntem olması gerekiyor (öz sınama açıkça test edilen nesnenin bir yöntemidir), ancak bir dış yöntemin tüm derleyici disiplinini alması gerekiyor ( nesnenin uygulama detaylarından bağımsız olmalıdır). Herhangi bir programlama dili, bir nesneyi disipline etme yeteneği sağlıyorsa s dış bir yöntemmiş gibi iç yöntemi. Yani bu önemli bir programlama dili tasarım konusudur.

Doğru programlama dili desteği yokken, bunu yapmanın en iyi yolu bir eşlik eden nesne oluşturmaktır. Diğer bir deyişle, kodladığınız her nesne için ("Big_Object" olarak adlandıralım), ayrıca "real" nesnesinin adıyla birleştirilen standart bir sonekten oluşan ikinci bir eşlik eden nesne oluşturursunuz (bu durumda, "Big_Object_Self_Test ") ve belirtimi tek bir yöntemden oluşuyor (" Big_Object_Self_Test.Self_Test (This_Big_Object: Big_Object) return Boolean; "). Eşlik eden nesne daha sonra ana nesnenin özelliklerine bağlı olacaktır ve derleyici, eşlik eden nesnenin uygulanmasına karşı bu tarifnamenin tüm disiplinini tamamen uygulayacaktır.

Bu, satır içi testlerin yapılmadığını öne süren çok sayıda yoruma yanıt olarak geliyor; çünkü test kodunu sürüm oluşturmalarından kaldırmak imkansız. Bu doğru değil. Hemen hemen tüm derleyiciler ve derleyiciler bunu zaten desteklemektedir; C, C ++, C # gibi derlenmiş dillerle bu derleyici yönergeleri adı verilen şeyle yapılır.

C # durumunda (c ++ 'ın da kullandığına inanıyorum, sözdizimi hangi derleyiciyi kullandığınıza bağlı olarak biraz farklı olabilir) bu nasıl yapabilirsiniz.

#define DEBUG //  = true if c++ code
#define TEST /* can also be defined in the make file for c++ or project file for c# and applies to all associated .cs/.cpp files */

//somewhere in your code
#if DEBUG
// debug only code
#elif TEST
// test only code
#endif

Bu, derleyici yönergelerini kullandığından, bayraklar ayarlanmadığında oluşturulan yürütülebilir dosyalarda kod bulunmaz. Bu aynı zamanda çoklu platformlar / donanımlar için "bir kez yaz, iki kez derle" programlarını böyle yapar.

Perl kodumuzla satır içi testleri kullanıyoruz. Bir satırda Test :: Inline , satır içi kodundan test dosyaları üreten bir modül var .

Testlerimi organize etme konusunda özellikle iyi değilim ve inline edildiklerinde daha kolay ve daha kolay kullanılmalarını sağladım.

Birkaç endişeye cevap vermek:

• Satır içi testler POD bölümlerinde yazılmıştır, bu nedenle gerçek kodun bir parçası değildirler. Tercüman tarafından yok sayılırlar, bu yüzden kod ihlali yoktur.
• Test bölümlerini gizlemek için Vim katlama kullanıyoruz . Gördüğünüz tek şey, test edilen her yöntemin üzerinde tek bir satırdır +-- 33 lines: #test----. Testle çalışmak istediğinizde, sadece genişletin.
• Test :: Inline modülü testleri normal TAP uyumlu dosyalara "derler", böylece geleneksel testlerle birlikte bulunabilirler.

Referans için:

• POD
• TAP

Erlang 2 aslında satır içi testleri destekliyor. Kodda kullanılmayan (örneğin bir değişkene atanmış veya geçen) herhangi bir boole ifadesi otomatik olarak bir test olarak değerlendirilir ve derleyici tarafından değerlendirilir; Eğer ifade yanlışsa, kod derlenmez.

Testleri ayırmanın başka bir nedeni, gerçek uygulamadan ziyade test için sık sık ek veya hatta farklı kütüphaneler kullanmanızdır. Testleri ve uygulamayı karıştırırsanız, uygulamadaki test kitaplıklarının yanlışlıkla kullanılması derleyici tarafından yakalanamaz.

Ayrıca, testler test ettikleri uygulama bölümlerinden çok daha fazla kod satırına sahip olma eğilimindedir, bu nedenle tüm testler arasında uygulamayı bulmakta sorun yaşarsınız. :-)

Bu doğru değil. Ünite testlerinizi, özellikle üretim rutini saf olduğunda, üretim kodu olduğunda, üretim kodunun yanına yerleştirmek çok daha iyidir.

Örneğin, .NET'te geliştiriyorsanız, test kodunuzu üretim meclisine koyabilir ve göndermeden önce bunları silmek için Neşter kullanabilirsiniz .