Özel / Korumalı yöntemler birim test altında olmalı mı?

TDD geliştirmede, tipik olarak yaptığınız ilk şey, arayüzünüzü oluşturmak ve ardından bu arayüze karşı birim testlerinizi yazmaya başlamaktır. TDD sürecinde ilerledikçe, arayüzü uygulayan bir sınıf oluşturursunuz ve ardından bir noktada birim testiniz geçebilir.

Şimdi sorum, arayüz tarafından açığa çıkan yöntemleri / özellikleri desteklemek için sınıfımda yazmam gerekebilecek özel ve korumalı yöntemlerle ilgili:

• Sınıftaki özel yöntemlerin kendi birim testleri olmalı mı?

• Sınıftaki korumalı yöntemlerin kendi birim testleri olmalı mı?

Düşüncelerim:

• Özellikle arayüzlere kod yazdığım için, onlar kara kutu oldukları için korumalı / özel yöntemler konusunda endişelenmemeliyim.

• Arayüzler kullandığım için, tanımlanan sözleşmenin arayüzü uygulayan farklı sınıflar tarafından düzgün bir şekilde uygulandığını doğrulamak için birim testleri yazıyorum, bu yüzden yine özel / korumalı yöntemler hakkında endişelenmemeliyim ve bunlar, arayüz tarafından tanımlanan yöntemler / özellikler.

• Kod kapsamım korumalı / özel yöntemlerin vurulduğunu göstermiyorsa, o zaman doğru birim testlerine sahip değilim veya kullanılmayan ve kaldırılması gereken kodum var.

Hayır, özel veya korumalı yöntemleri test etmeyi düşünmüyorum. Bir sınıfın özel ve korumalı yöntemleri genel arabirimin parçası değildir, bu nedenle genel davranışı açığa çıkarmazlar. Genellikle bu yöntemler, testinizi yeşile döndükten sonra uyguladığınız yeniden düzenlemeler tarafından oluşturulur.

Bu nedenle, bu özel yöntemler, genel arabiriminizin davranışını ortaya koyan testlerle dolaylı olarak test edilir .

Daha felsefi bir kayda göre, yöntemleri değil davranışı test ettiğinizi unutmayın. Bu nedenle, test edilen sınıfın yapabileceği şeyleri düşünürseniz, test edebileceğiniz ve sınıfın beklendiği gibi davrandığını iddia edebildiğiniz sürece, sınıf tarafından dahili olarak kullanılan özel (ve korumalı) yöntemler olup olmadığı bu davranış alakasızdır. Bu yöntemler, genel davranışın uygulama ayrıntılarıdır.

Posterlerin çoğuna katılmıyorum.

En önemli kural şudur: ÇALIŞMA KODU TROMPALARI KAMU / KORUMALI / ÖZEL hakkında teorik KURALLAR.

Kodunuz iyice test edilmelidir. Oraya, korumalı / özel yöntemleri yeterince kullanan herkese açık yöntemler için testler yazarak ulaşabilirseniz, bu harika.

Yapamıyorsanız, o zaman ya yeniden düzenleyin, ya da korumalı / özel kuralları esnetin.

Çocuklara test yapan bir psikolog hakkında harika bir hikaye var. Her çocuğa, her iki ucuna birer ip iliştirilmiş iki tahta tahta verdi ve mümkün olduğunca hızlı bir şekilde ayakları yere değmeden bir odayı geçmelerini istedi. Bütün çocuklar tahtaları küçük kayaklar gibi kullandılar, her bir tahtada bir ayak, onları halatlardan tutarak ve zeminde kayarak. Sonra onlara aynı görevi verdi, ancak yalnızca TEK bir tahta kullandı. Tek bir tahtanın her iki ucunda birer ayak olacak şekilde yerde döndüler / "yürüdüler" - ve DAHA HIZLI idiler!

Sırf Java'nın (veya hangi dilin) ​​bir özelliği olması (özel / korumalı / genel), kullandığınız için daha iyi kod yazdığınız anlamına gelmez!

Şimdi, bu çatışmayı optimize etmenin / en aza indirmenin her zaman yolları olacaktır. Çoğu dilde, bir yöntemi korumalı hale getirebilir (genel yerine) ve test sınıfını aynı pakete (veya her neyse) koyabilirsiniz ve yöntem test için kullanılabilir olacaktır. Diğer posterler tarafından açıklandığı gibi yardımcı olabilecek ek açıklamalar vardır. Özel yöntemlere (iğrenç) ulaşmak için yansımayı kullanabilirsiniz.

Bağlam da önemlidir. Harici kişiler tarafından kullanılmak üzere bir API yazıyorsanız, genel / özel daha önemlidir. Dahili bir projeyse - gerçekten kimin umurunda?

Ancak günün sonunda, test eksikliğinden kaç tane hataya neden olduğunu düşünün. Ardından "aşırı görünür" yöntemlerin neden olduğu hatalarla karşılaştırın. Bu cevap, kararınızı yönlendirmeli.

Sen yazdın:

TDD geliştirmede, tipik olarak yaptığınız ilk şey, arayüzünüzü oluşturmak ve ardından bu arayüze karşı birim testlerinizi yazmaya başlamaktır. TDD sürecinde ilerledikçe, arayüzü uygulayan bir sınıf oluşturursunuz ve ardından bir noktada birim testiniz geçebilir.

Lütfen bunu BDD dilinde yeniden ifade etmeme izin verin :

Bir sınıfın neden değerli olduğunu ve nasıl davrandığını açıklarken, genellikle yaptığınız ilk şey, genellikle arayüzü * aracılığıyla sınıfın nasıl kullanılacağına dair bir örnek oluşturmaktır. İstediğiniz davranışı ekledikçe, sonunda bu değeri sağlayan bir sınıf yaratırsınız ve sonra bir noktada örneğiniz çalışır.

* Gerçek Interfaceveya basitçe sınıfın erişilebilir API'si olabilir, örneğin: Ruby'nin arayüzleri yoktur.

Bu yüzden özel yöntemleri test etmiyorsunuz - çünkü test, sınıfın nasıl kullanılacağına dair bir örnektir ve bunları gerçekten kullanamazsınız. İsterseniz yapabileceğiniz bir şey, özel yöntemlerdeki sorumlulukları işbirliği yapan bir sınıfa devretmek ve ardından bu yardımcı ile alay etmek / taslaklamaktır.

Korumalı yöntemlerle, sınıfınızı genişleten bir sınıfın belirli bir davranışı olması ve bir değer sağlaması gerektiğini söylüyorsunuz. Daha sonra bu davranışı göstermek için sınıfınızın uzantılarını kullanabilirsiniz. Örneğin, sıralı bir koleksiyon sınıfı yazıyorsanız, aynı içeriğe sahip iki uzantının eşitlik gösterdiğini göstermek isteyebilirsiniz.

Bu yardımcı olur umarım!

Sınıfınız için birim testleri yazarken, sınıfın işlevselliğinin doğrudan genel arabirimdeki yöntemde uygulanıp uygulanmadığını veya bir dizi özel yöntemde uygulanıp uygulanmadığını umursamamanız gerekir. Yani evet, özel yöntemlerinizi test etmelisiniz, ancak bunu yapmak için onları doğrudan test kodunuzdan çağırmanıza gerek yoktur (özel yöntemleri doğrudan test etmek, uygulamanızı testlerinizle sıkı bir şekilde birleştirir ve yeniden düzenlemeyi gereksiz yere zorlaştırır).

Korumalı yöntemler, sınıfınız ve onun gelecekteki çocukları arasında farklı bir sözleşme oluşturur, bu nedenle, sözleşmenin iyi tanımlanmasını ve uygulanmasını sağlamak için bunu, genel arayüzünüzle aynı ölçüde test etmelisiniz.

Hayır! Yalnızca arayüzleri test edin.

TDD'nin en büyük faydalarından biri, özel yöntemleri uygulamayı nasıl seçmiş olursanız olun, arayüzün çalıştığından emin olmaktır.

Başkalarının yukarıda söylediklerini tamamlayarak, korumalı yöntemlerin bir tür arayüzün parçası olduğunu söyleyebilirim: basitçe, bileşim yerine kalıtıma maruz kalan bir yöntemdir, bu, arayüzleri değerlendirirken herkesin düşünmeye meyilli olduğu şeydir.

Bir yöntemi özel yerine korumalı olarak işaretlemek, üçüncü taraf kodu tarafından kullanılması beklendiği anlamına gelir, bu nedenle, hem kalıtım hem de kompozisyon için açık olan genel yöntemlerle tanımlanan normal arayüzlerde olduğu gibi, bir tür sözleşmenin tanımlanması ve test edilmesi gerekir. .

Test yazmak için iki neden var:

1. Beklenen davranışı öne sürmek
2. Davranışın gerilemesini önleme

Kabul (1) Beklenen davranışı ileri sürmek:

Beklenen davranışı öne sürerken, kodun olması gerektiğini düşündüğünüz gibi çalıştığından emin olmak istersiniz. Bu, herhangi bir geliştiricinin herhangi bir kod türünü uygularken gerçekleştireceği rutin manuel doğrulamanızı gerçekleştirmenin etkili bir şekilde otomatik bir yoludur:

• Az önce yazdığım işe yaradı mı?
• Bu döngü gerçekten bitiyor mu?
• Düşündüğüm sırada mı dönüyor?
• Bu boş bir girdi için işe yarar mı?

Bunlar hepimizin kafamızda cevapladığı sorular ve normalde kodu kafamızda da çalıştırmaya çalışırız, işe yarıyor gibi göründüğünden emin oluruz. Bu durumlarda, bilgisayarın bunları kesin bir şekilde yanıtlamasını sağlamak genellikle yararlıdır. Bu yüzden, bunu yaptığını iddia eden bir birim testi yazıyoruz. Bu bize kodumuza güven verir, hataları erken bulmamıza yardımcı olur ve hatta kodu gerçekten uygulamaya yardımcı olabilir.

Gerekli olduğunu düşündüğünüz her yerde bunu yapmak iyi bir fikirdir. Anlaması biraz zor olan veya önemsiz olmayan herhangi bir kod. Önemsiz kod bile bundan yararlanabilir. Her şey kendi özgüveninizle ilgili. Bunu ne sıklıkla yapacağınız ve ne kadar ileri gideceğiniz kendi memnuniyetinize bağlı olacaktır. Kendinizden emin bir şekilde Evet cevabını verebileceğiniz zaman durun: Bunun çalıştığından emin misiniz?

Bu tür testler için, görünürlük, arayüzler veya bunlardan herhangi biri ile ilgilenmezsiniz, yalnızca çalışan kodlara sahip olmayı önemsersiniz. Yani evet, soruya Evet yanıtı vermeniz için test edilmeleri gerektiğini düşünüyorsanız, özel ve korumalı yöntemleri test edersiniz.

(2) Davranışın gerilemesini önleme:

Çalışma kodunu aldıktan sonra, bu kodu gelecekteki hasarlardan korumak için bir mekanizmaya sahip olmanız gerekir. Kaynağınıza ve yapılandırmanıza bir daha kimse dokunmasaydı, buna ihtiyacınız olmazdı, ancak çoğu durumda siz veya başkaları yazılımınızın kaynağına ve yapılandırmalarına dokunacaksınız. Bu dahili kurcalamanın, çalışma kodunuzu kırma olasılığı yüksektir.

Mekanizmalar çoğu dilde, bu hasara karşı korunmanın bir yolu olarak zaten mevcuttur. Görünürlük özellikleri bir mekanizmadır. Özel bir yöntem izole edilmiş ve gizlenmiştir. Kapsülleme, şeyleri bölümlere ayırdığınız başka bir mekanizmadır, böylece diğer bölmeleri değiştirmek diğerlerini etkilemez.

Bunun genel mekanizmasına sınıra kodlama denir. Kodun bölümleri arasında sınırlar oluşturarak, bir sınırın içindeki her şeyi onun dışındaki şeylerden korursunuz. Sınırlar, etkileşim noktası ve nesnelerin etkileşim kurduğu sözleşme haline gelir.

Bu, bir sınırda yapılan değişikliklerin, arayüzünü kırarak veya beklenen davranışını bozarak, ona dayanan diğer sınırlara zarar vereceği ve muhtemelen kıracağı anlamına gelir. Bu nedenle, bu sınırları hedefleyen ve anlamsal ve davranışta değişmediklerini iddia eden bir birim testine sahip olmak iyi bir fikirdir.

Bu sizin tipik birim testinizdir, TDD veya BDD'den bahsederken en çok herkesin bahsettiği bir testtir. Önemli olan, sınırları sertleştirmek ve onları değişimden korumaktır. Bunun için özel yöntemleri test etmek istemezsiniz çünkü özel bir yöntem sınır değildir. Korumalı yöntemler kısıtlı bir sınırdır ve onları korurdum. Dünyaya maruz kalmazlar, ancak yine de diğer bölmelere veya "Birimlere" maruz kalırlar.

Bu ne yapmak için?

Gördüğümüz gibi, arayüzlerimizin değişmediğini iddia etmek için herkese açık ve korumalı yöntemleri birim test etmek için iyi bir neden var. Ayrıca, uygulama çalışmalarımızı ileri sürmek için özel yöntemleri test etmek için iyi bir neden var. Öyleyse hepsini test etmeli miyiz?

Evet ve hayır.

İlk olarak : Görünürlüğü ne olursa olsun kodunuzun çalıştığından emin olmak için çoğu durumda çalıştığına dair kesin bir kanıta ihtiyacınız olduğunu düşündüğünüz tüm yöntemleri test edin. Ardından bu testleri devre dışı bırakın. Orada iş yaptılar.

Son olarak : Sınırlarınız için testler yazın. Sisteminizin diğer birimleri tarafından kullanılacak her nokta için bir birim testi yaptırın. Bu testin anlamsal sözleşmeyi, yöntem adını, argüman sayısını vb. Belirttiğinden emin olun. Ayrıca testin ünitenin mevcut davranışını gösterdiğinden emin olun. Testiniz ünitenin nasıl kullanılacağını ve ünitenin neler yapabileceğini göstermelidir. Her kod aktarımında çalışması için bu testleri etkin tutun.

NOT: İlk test kümesini devre dışı bırakmanızın nedeni, yeniden düzenleme çalışmasının gerçekleşmesine izin vermektir. Aktif bir test, bir kod kuplajıdır. Test ettiği kodun ileride değiştirilmesini önler. Bunu sadece arayüzleriniz ve etkileşim sözleşmeleriniz için istiyorsunuz.

Hayır, özel yöntemleri test etmemelisiniz (zaten yansıma gibi korkunç bir şey kullanmadan nasıl olurdunuz). Korumalı yöntemlerle, C # 'da biraz daha az aşikar olan şeyleri dahili olarak koruyabilirsiniz ve bence bunu, tüm işlevlerini şablon kalıp yöntemleri aracılığıyla uygulayan türetilmiş sınıfları test etmek için yapmanın uygun olduğunu düşünüyorum.

Ancak, genel olarak, herkese açık yöntemlerin çok fazla şey yaptığını düşünüyorsanız, sınıflarınızı daha atomik sınıflara göre yeniden düzenleme ve sonra bu sınıfları test etme zamanı gelmiştir.

@ Kwbeam'in özel yöntemleri test etmeme konusundaki yanıtına ben de katılıyorum. Ancak, vurgulamak istediğim önemli bir nokta - korumalı yöntemler, bir sınıfın dışa aktarılan API'sinin bir parçasıdır ve bu nedenle test edilmelidir.

Korumalı yöntemler genel erişime açık olmayabilir, ancak kesinlikle alt sınıfların bunları kullanması / geçersiz kılması için bir yol sunuyorsunuz. Sınıfın dışındaki bir şey bunlara erişebilir ve bu nedenle bu korunan üyelerin beklenen şekilde davranmasını sağlamanız gerekir. Bu yüzden özel yöntemleri test etmeyin, ancak herkese açık ve korumalı yöntemleri test edin.

Eleştirel mantık içeren özel bir yöntemin olduğuna inanıyorsanız, onu ayrı bir nesneye çıkarmaya, izole etmeye ve davranışını test etmenin bir yolunu sağlamaya çalışırım.

Umarım yardımcı olur!

Yüksek kod kapsamını hedefliyorsanız (tavsiye ederim), özel veya korumalı olmasına bakılmaksızın tüm yöntemlerinizi test etmelisiniz.

Korumalı bir tür farklı tartışma noktasıdır, ancak özetle, orada olmamalıdır. Ya konuşlandırılan kodda kapsüllemeyi bozar ya da sizi bu sınıftan miras almaya zorlar, sadece birim testi için, hatta bazen devralmanız gerekmiyor.

Bir yöntemi müşteriye gizlemek (özel hale getirmek), ona denetlenmeme ayrıcalığına sahip olma hakkı vermez. Bu nedenle, daha önce belirtildiği gibi halka açık yöntemlerle test edilebilirler.

Herkese katılıyorum: Sorunuzun cevabı 'hayır'.

Aslında, yaklaşımınız ve düşünceleriniz, özellikle de kod kapsamı konusunda tamamen haklısınız.

Ayrıca sorunun (ve 'hayır' cevabının) sınıflara tanıtabileceğiniz genel yöntemler için de geçerli olduğunu ekleyeceğim.

• Başarısız bir test geçişi yaptıkları için yöntemler (genel / korumalı veya özel) eklerseniz, TDD hedefine aşağı yukarı ulaşmış olursunuz.
• TDD'yi ihlal etmeye karar verdiğiniz için yöntemler (genel / korumalı veya özel) eklerseniz, kod kapsamınız bunları yakalamalı ve sürecinizi iyileştirebilmelisiniz.

Ayrıca, C ++ için (ve yalnızca C ++ için düşünmeliyim), sınıfın yalnızca uyguladığı arabirim aracılığıyla kullanılması gerektiğini belirtmek için arabirimleri yalnızca özel yöntemleri kullanarak uygularım. Testlerimden uygulamama eklenen yeni yöntemleri yanlışlıkla çağırmamı durduruyor

İyi bir tasarım, uygulamayı birden çok test edilebilir birime bölmek anlamına gelir. Bunu yaptıktan sonra, bazı birimler genel API'ye maruz kalır, ancak bazıları olmayabilir. Ayrıca, maruz kalan birimler ile bu "dahili" birimler arasındaki etkileşim noktaları da pubik API'nin bir parçası değildir.

Bence, tanımlanabilir birime sahip olduğumuzda, genel API yoluyla açığa çıkıp çıkmamasına bakılmaksızın birim testlerinden faydalanacağız.