TDD Kırmızı-Yeşil-Refaktörü ve özel hale getirilmiş yöntemleri test etmek için nasıl / nasıl

Anladığım kadarıyla, çoğu insan özel yöntemlerin doğrudan test edilmemesi gerektiği, bunun yerine kamusal yöntemler ne şekilde olursa olsun denenmesi gerektiği konusunda hemfikir. Onların noktasını görebiliyorum, ancak "TDD'nin Üç Yasasını" izlemeye çalıştığımda ve "Kırmızı - yeşil - refaktör" döngüsünü kullanmaya başladığımda bazı problemlerim var. Bence en iyi örnekle açıklanıyor:

Şu anda, bir dosyayı okuyabilen (sekmeyle ayrılmış veriler içeren) ve sayısal olmayan veriler içeren tüm sütunları filtreleyebilen bir programa ihtiyacım var. Sanırım bunu yapmak için halihazırda bazı basit araçlar var, ancak onu baştan çizmeye karar verdim, çünkü çoğunlukla TDD ile pratik yapmanın güzel ve temiz bir proje olacağını düşündüm.

Yani, ilk önce "kırmızı şapkayı taktım", yani, başarısız bir teste ihtiyacım var. Sayısal olmayan tüm alanları bir çizgide bulan bir yönteme ihtiyacım olacağını düşündüm. Bu yüzden basit bir test yazıyorum, tabii ki derhal derlenemiyor, bu yüzden fonksiyonun kendisini yazmaya başlıyorum ve bir kaç ileri ve geri (kırmızı / yeşil) döngüden sonra bir çalışma fonksiyonuna ve tam bir teste sahibim.

Sonra, her seferinde bir satır dosya okuyan ve bir satırda okuyan "gatherNonNumericColumns" işleviyle devam ediyorum ve sonunda çıkarılması gereken tüm sütunları toplamak için her satırdaki "findNonNumericFields" işlevimi çağırıyorum. Birkaç kırmızı-yeşil çevrimli ve yine bir çalışma fonksiyonu ve tam bir test olan bittim.

Şimdi yeniden düşünmeliyim. "FindNonNumericFields" yöntemim yalnızca "gatherNonNumericColumns" uygularken buna ihtiyacım olacağını düşündüğüm için tasarlandığından, "findNonNumericFields" öğesinin özel olmasına izin vermenin makul olacağını düşünüyorum. Ancak bu, ilk testlerimi bozacak, çünkü test ettikleri yönteme artık ulaşamayacaklardı.

Bu yüzden, özel bir yöntem ve onu test eden bir test paketi ile bitirdim. Birçok insan özel yöntemlerin test edilmemesi gerektiğini tavsiye ettiğinden, burada kendimi bir köşeye boyattım gibi geliyor. Ama tam olarak nerede başarısız oldum?

Daha yüksek bir düzeyde başlayabilirdim, nihayetinde kamu yöntemim haline geleceğini test eden bir test yazdım (yani, FindAndFilterOutAllNonNumericalColumns), ancak bu TDD'nin tüm noktasına biraz karşı geliyor (en azından Bob Amca'ya göre). : Yazma testleri ve üretim kodu arasında sürekli geçiş yapmalısınız ve herhangi bir zamanda, tüm testleriniz son dakika içinde çalıştı. Çünkü bir kamu yöntemi için test yazarak başlarsam, testin kamuoyunu test etmesi için özel yöntemlerde tüm detayları öğrenmeden önce birkaç dakika (veya çok karmaşık durumlarda saatlerce veya hatta günler) olacak yöntem geçer.

Peki ne yapmalı? TDD (hızlı kırmızı-yeşil-refactor çevrimi ile) sadece özel yöntemlerle uyumlu değil mi? Yoksa tasarımımda bir hata mı var?

Birimler

Sorunun tam olarak nerede başladığını tam olarak tespit edebilirim:

Sayısal olmayan tüm alanları bir çizgide bulan bir yönteme ihtiyacım olacağını düşündüm.

Bunu hemen kendinize sormanız gerekir: " gatherNonNumericColumnsAynı olanın bir parçası mı yoksa bir parçası olacak mı?"

Eğer cevap " evet, ayrı " ise, hareket tarzınız basittir: bu yöntemin uygun bir sınıfta halka açık olması gerekir, bu yüzden bir birim olarak test edilebilir. Zihniyetiniz, "Bir yöntemi denemeye ihtiyacım var, ayrıca başka bir yöntemi de test etmeye ihtiyacım var" gibi bir şey.

Yine de söylediklerine göre, cevabın " hayır, aynı şeyin" olduğunu düşündün . Bu noktada, planınız artık tam olarak yazmak, findNonNumericFields sonra da yazmak olmak olmamalıdır gatherNonNumericColumns. Bunun yerine, basitçe yazmak gerekir gatherNonNumericColumns. Şimdilik, findNonNumericFieldsbir sonraki kırmızı test durumunuzu seçerken ve yeniden düzenleme yaparken aklınızdaki yerin muhtemel bir parçası olmalıdır. Bu kez zihniyetiniz "Bir yöntemi test etmeyi test etmem gerekiyor ve bunu yaparken de bitmiş uygulamamın muhtemelen bu diğer yöntemi içereceğini göz önünde bulundurmalıyım" dır .

Kısa bir döngü tutmak

Gerektiğini yukarıda yapmak değil size sondan bir önceki paragrafta tarif sorunlara neden:

Çünkü bir kamu yöntemi için test yazarak başlarsam, testin kamuoyunu test etmesi için özel yöntemlerde tüm detayları öğrenmeden önce birkaç dakika (veya çok karmaşık durumlarda saatlerce veya hatta günler) olacak yöntem geçer.

Hiçbir şekilde bu teknik, yalnızca tamamını findNonNumericFieldssıfırdan uyguladığınızda yeşile dönecek olan kırmızı bir test yazmanızı gerektirmez . Çok daha büyük olasılıkla, findNonNumericFieldsbirkaç döngü boyunca oluşturulacak ve nihayetinde bir yeniden yapılanma işlemi sırasında çıkacak olan, test ettiğiniz genel yöntemde bir kod olarak başlayacaktır.

Yol Haritası

Bu belirli örnek için yaklaşık bir yol haritası vermek için, kullandığınız test durumlarını tam olarak bilmiyorum, ancak gatherNonNumericColumnsgenel yönteminiz olarak yazdığınızı söyleyin . O zaman büyük olasılıkla test senaryoları findNonNumericFields, her biri yalnızca bir satır içeren bir tablo kullanarak yazdıklarınızla aynı olacaktır . Bu tek satırlık senaryo tam olarak uygulandığında ve sizi metodu çıkarmaya zorlamak için bir test yazmak istediğinizde, yinelemenizi eklemenizi gerektiren iki satırlık bir dava yazarsınız.

Birçok insan birim testinin metot temelli olduğunu düşünüyor; değil. Mantıklı olan en küçük birim etrafında kurulmalıdır. Çoğu şey için bu, sınıfın bütün bir varlık olarak test etmeniz gereken şey olduğu anlamına gelir. Bireysel yöntemler değil.

Şimdi açık bir şekilde sınıfa yöntemler çağırıyor olacaksınız, ancak testleri karaliz nesnesine uyguladığınızı düşünmelisiniz, bu nedenle sınıfınızın sağladığı mantıksal işlemleri görebilmelisiniz; bunlar test etmeniz gereken şeyler. Sınıfınız mantıksal işlemin çok karmaşık olduğu kadar büyükse, önce düzeltilmesi gereken bir tasarım sorununuz vardır.

Bin yöntemli bir sınıf test edilebilir görünebilir, ancak her yöntemi tek tek test ederseniz, sınıfı gerçekten test etmiyorsunuzdur. Bazı sınıflar, bir yöntem çağrılmadan önce, örneğin veri göndermeden önce bağlantı kurması gereken bir ağ sınıfı gibi belirli bir durumda olmalarını gerektirebilir. Veri gönderme yöntemi tüm sınıftan bağımsız olarak kabul edilemez.

Bu nedenle, özel yöntemlerin testle alakasız olduğunu görmelisiniz. Özel yöntemlerinizi sınıfınızın genel arayüzünü arayarak uygulayamıyorsanız, bu özel yöntemler işe yaramaz ve yine de kullanılamaz.

Bence pek çok insan özel yöntemleri test edilebilir birimlere dönüştürmeye çalışıyor, çünkü onlar için test yapmak kolay görünüyor, ancak bu testin ayrıntı derecesini çok fazla alıyor. Martin Fowler diyor

Birimin sınıf olduğu nosyonuyla başlasam da, sık sık birbiriyle yakından ilgili dersler alıyorum ve onları tek bir ünite olarak görüyorum.

Nesne yönelimli bir sistem için çok anlamlı, nesneler birim olarak tasarlandı. Tek tek metotları test etmek istiyorsanız, belki de C gibi bir prosedür sistemi ya da tamamen statik fonksiyonlardan oluşan bir sınıf oluşturmalısınız.

Veri toplama yöntemlerinin testleri hak edecek kadar karmaşık olması ve bazı hedeflerin bir kısmından ziyade kendi amaçlarına göre kendi asıl hedefinden ayrılmasının çözüme götürdüğü gerçeği : bu yöntemleri özel değil , diğer sınıfın üyeleri yapın. Bu toplama / filtreleme / tablolama işlevselliği sağlar.

Ardından, yardımcı sınıfın aptal veri-munging yönleri için testler (örneğin, "karakterlerden rakamları ayırma") ve başka bir yerde birincil hedefiniz için testler (örneğin, "satış rakamlarını elde etme"), ve iş mantığınız için yapılan testlerde temel filtreleme testlerini tekrar etmeniz gerekmiyor.

Oldukça genel olarak, bir şeyi yapan sınıfınız, birincil amacı için gerekli olan ancak bundan ayrı bir şey yapmak için kapsamlı bir kod içeriyorsa, bu kod başka bir sınıfta yaşamalı ve ortak yöntemlerle çağrılmalıdır. Yanlışlıkla bu kodu içeren bir sınıfın özel köşelerinde gizlenmemelidir . Bu, aynı zamanda test edilebilirliği ve anlaşılabilirliği geliştirir.

Şahsen, testleri yazarken uygulama zihniyetinde ileri gittiğinizi hissediyorum. Sen kabul belirli yöntemler gerekir. Ama sınıfın yapması gerekeni yapmaları için onlara gerçekten ihtiyacın var mı? Birisi bir araya gelerek ve onları içeriden ayırdıysa sınıf başarısız olur mu? Sınıfı kullanıyor olsaydınız (ve bence test cihazının zihniyeti olmalı), sayıları kontrol etmek için açık bir yöntem olup olmadığını gerçekten daha az önemseyebilirsiniz.

Bir sınıfın ortak arayüzünü test etmelisiniz. Özel uygulama bir nedenden dolayı özeldir. Bu, kamu arayüzünün bir parçası değildir, çünkü gerekli değildir ve değişebilir. Bir uygulama detayı.

Genel arayüze karşı testler yazarsanız, karşılaştığınız sorunu asla çözemezsiniz. İsterseniz özel yöntemlerinizi kapsayan (harika) genel arabirim için test senaryoları oluşturabilirsiniz veya olamaz. Bu durumda, özel yöntemler hakkında çok fazla düşünmek ve yine de ulaşılamaması durumunda hepsini tamamen hurdaya çıkarmak zaman olabilir.

Sınıfın dahili olarak ne yapmasını beklediğinizi temel alarak TDD yapmazsınız.

Test durumlarınız, sınıf / işlevsellik / programın dış dünyaya yapması gerekenlere dayanmalıdır. Örnekte, kullanıcı hiç okuyucunuzu sınıfla arayacak mı?find all the non-numerical fields in a line?

Cevap "hayır" ise, ilk etapta yazmak kötü bir sınavdır. Testin işlevsellik üzerine bir sınıf / arayüz düzeyinde yazmasını istiyorsunuz - "sınıf metodu bunun işe yaraması için ne yapmalı" seviyesine değil, testiniz budur.

TDD'nin akışı:

• kırmızı (dış dünyaya sınıf / nesne / fonksiyon / etc ne yapıyor?)
• yeşil (bu dış dünya işlevinin çalışması için minimum kodu yazın)
• refactor (bu işi yapmak için daha iyi kod nedir)

Bunu yapmak DEĞİLDİR "çünkü gelecekte X'e özel bir yöntem olarak ihtiyacım olacak, uygulayalım ve önce test edeyim." Kendinizi bunu yaparken buluyorsanız, yanlış olarak "kırmızı" aşamayı yapıyorsunuzdur. Buradaki senin sorunun gibi görünüyor.

Kendinizi sık sık özel yöntemler haline getiren yöntemler için sınamalar bulursanız, birkaç şeyden birini yapıyorsunuz:

• Arabiriminizi / genel düzeydeki kullanım durumlarınızı doğru bir şekilde anlamadığınızdan, bunlar için bir test yazabilecek kadar
• Tasarımınızı önemli ölçüde değiştirmek ve birkaç testi tekrar gözden geçirmek (bu işlevselliğin yeni testlerde test edilip edilmediğine bağlı olarak iyi bir şey olabilir)

Genel olarak test etme ile ilgili ortak bir yanılgı ile karşılaşıyorsunuz.

Test etmeye yeni başlayan çoğu insan şu şekilde düşünmeye başlar:

• F işlevi için bir test yaz
• F uygulayın
• G fonksiyonu için bir test yaz
• F çağrısını kullanarak G uygulamasını
• H işlevi için bir test yaz
• G çağrısını kullanarak H uygulayın

ve bunun gibi.

Buradaki problem aslında H fonksiyonu için birim testiniz olmamasıdır. H test etmesi gereken test aslında H, G ve F'yi aynı anda test ediyor.

Bunu çözmek için, test edilebilir birimlerin asla birbirlerine değil, arayüzlerine bağlı olmaları gerektiğini anlamalısınız . Durumda, ünitelerin basit fonksiyonlar olduğu durumlarda, arayüzler sadece çağrı imzalarıdır. Bu nedenle G'yi, F ile aynı imzayı taşıyan herhangi bir fonksiyonla kullanılabilecek şekilde uygulamalısınız .

Bunun tam olarak nasıl yapılabileceği programlama dilinize bağlıdır. Birçok dilde işlevleri (veya işaretçileri) diğer işlevlerin argümanları olarak iletebilirsiniz. Bu, her işlevi ayrı ayrı test etmenize olanak sağlar.

Teste Dayalı Geliştirme sırasında yazdığınız testlerin, bir sınıfın genel API'sini doğru bir şekilde uyguladığından ve aynı zamanda genel API'nin test edilmesinin ve kullanımının kolay olduğundan emin olması gerekir.

Elbette bu API'yi uygulamak için özel yöntemler kullanabilirsiniz, ancak TDD yoluyla testler oluşturmanıza gerek yoktur - genel API düzgün çalışacağından işlevsellik test edilecektir.

Şimdi, kişisel metotlarınızın bağımsız testlere layık olacak kadar karmaşık olduğunu varsayalım - ancak orijinal sınıfınızın genel API'sinin bir parçası olarak bir anlam ifade etmiyorlar. Eh, bu muhtemelen onların başka bir sınıftaki ortak yöntem olması gerektiği anlamına gelir - birincisi, asıl sınıfınızın kendi uygulamasında yararlandığı bir yöntem.

Yalnızca genel API'yi test ederek, gelecekte uygulama ayrıntılarını değiştirmeyi çok daha kolaylaştırıyorsunuz. Yardımcı olmayan testler, daha sonra keşfettiğiniz bazı zarif yeniden düzenlemeyi desteklemek için yeniden yazılmaları gerektiğinde sizi rahatsız edecektir.

Bence doğru cevap, kamu yöntemleriyle başlamakla ilgili elde ettiğiniz sonuçtur. Bu yöntemi çağıran bir test yazarak başlarsınız. Bu başarısız olur, bu nedenle hiçbir şey yapmadan bu ada sahip bir yöntem yaratırsınız. Sonra belki bir dönüş değeri kontrol eden bir testte hak olabilirsiniz.

(İşlevlerinizin ne yaptığı konusunda tam olarak net değilim. Sayısal olmayan değerlerin çıkarıldığı dosya içeriğinde bir dize döndürüyor mu?)

Metodunuz bir string döndürürse, o dönüş değerini kontrol edin. Yani sadece onu inşa etmeye devam ediyorsun.

Özel bir yöntemle gerçekleşen herhangi bir şeyin, işleminiz sırasında bir noktada ortak yöntemde olması gerektiğini düşünüyorum ve sonra yalnızca yeniden düzenleme adımının bir parçası olarak özel yönteme taşındı. Yeniden yapılanma, bildiğim kadarıyla başarısız testlerden geçmeyi gerektirmiyor. İşlevsellik eklerken yalnızca başarısız testlere ihtiyacınız var. Hepsinin geçmesini sağlamak için yeniden ateşleyiciden sonra testlerinizi yapmanız yeterli.

Burada kendimi bir köşeye boyadım gibi geliyor. Ama tam olarak nerede başarısız oldum?

Eski bir atasözü var.

Planlamayı başaramazsan, planın başarısız olur.

İnsanlar TDD'nizde sadece oturup, testler yazdığınızı ve tasarımın sihirli bir şekilde gerçekleşeceğini düşünüyor gibi görünüyor. Bu doğru değil. Yüksek düzeyde bir planın olması gerekir. İlk önce arayüzü (genel API) tasarlarken TDD'den en iyi sonuçları aldığımı öğrendim. Şahsen, önce interfacesınıfı tanımlayan bir gerçek yaratıyorum .

gasp Herhangi bir test yapmadan önce bazı "kod" yazdım! Hayır, hayır. Yapmadım İzlenecek bir sözleşme yazdım , bir tasarım . Grafik kağıdındaki UML diyagramını not ederek benzer sonuçlar elde edebileceğinizden şüpheleniyorum. Mesele şu ki, bir planın olmalı. TDD, bir kod parçasına saldırmaktan kurtulacak bir lisans değildir.

"Önce Test" bir yanlış isim gibi hissediyorum. Önce Tasarım, sonra test et.

Elbette, lütfen başkalarının kodunuzdan daha fazla sınıf çıkarmak için verdikleri tavsiyelere uyun. Bir sınıfın iç kısımlarını test etme zorunluluğunu hissederseniz, bu iç kısımları kolayca test edilebilecek bir birime çıkartın ve enjekte edin.

Unutmayın ki testler de yeniden canlandırılabilir! Bir yöntemi özel yaparsanız, genel API'yi düşürürsünüz ve bu nedenle bu "kaybedilen işlevsellik" (AKA azaltılmış karmaşıklık) için ilgili bazı testleri atmak tamamen kabul edilebilir.

Diğerleri, özel yönteminizin ya diğer API testlerinizin bir parçası olarak çağrılacağını ya da erişilemeyeceğini ve dolayısıyla silinebileceğini söyledi. Aslında, yürütme yollarını düşünürsek işler daha iyi anlaşılır .

Örneğin, bölünme gerçekleştiren bir genel yöntemimiz varsa, sıfıra bölme ile sonuçlanan yolu test etmek isteyebiliriz. Biz yöntemi özel yaparsak, bir seçim olsun: ya biz bölünme-by-sıfıra yolunu düşünebiliriz, ya biz diğer yöntemlerle denir nasıl dikkate alarak bu yolu ortadan kaldırabilir.

Bu şekilde, bazı testlerden vazgeçebiliriz (örneğin, sıfıra bölme) ve kalan genel API açısından diğerlerini yeniden değerlendirebiliriz. Tabii ki, ideal bir dünyada, mevcut testler kalan tüm yollarla ilgilenir, ancak gerçeklik her zaman bir uzlaşmadır;)

Özel bir yöntemin başka bir sınıfın genel yöntemi haline getirilebileceği zamanlar vardır.

Örneğin, iş parçacığı güvenliği olmayan özel sınıflarınız olabilir ve sınıfı geçici bir durumda bırakabilirsiniz. Bu yöntemler, birinci sınıfınız tarafından özel olarak tutulan ayrı bir sınıfa taşınabilir. Bu nedenle, sınıfınız bir Queue ise, genel yöntemleri olan bir InternalQueue sınıfınız olabilir ve Queue sınıfı, InternalQueue örneğini özel olarak tutar. Bu, dahili kuyruğu test etmenize izin verir ve ayrıca Dahili Kuyruktaki bireysel işlemlerin ne olduğunu da netleştirir.

(List sınıfının olmadığını hayal ettiğinizde ve List işlevlerini bunları kullanan sınıfta özel yöntemler olarak uygulamaya çalıştıysanız, bu en açık olanıdır.)

Dilinizin neden sadece herkese açık ve tamamen özel olmak üzere iki gizlilik düzeyi olduğunu merak ediyorum.

Herkese açık olmayan yöntemlerinizi pakete erişilebilir ya da bunun gibi bir şeyle düzenleyebilir misiniz? Ardından, testlerinizi aynı pakete yerleştirin ve ortak arabirimin bir parçası olmayan iç işleri test etmenin tadını çıkarın. Derleme sisteminiz bir sürüm ikili oluştururken testleri hariç tutacaktır.

Elbette bazen tanımlayıcı sınıftan başka hiçbir şey için erişilebilir olmayan, gerçekten özel yöntemlere ihtiyaç duyabilirsiniz. Umarım tüm bu yöntemler çok küçüktür. Genel olarak yöntemleri küçük tutmak (örneğin 20 satırın altında) çok yardımcı olur: test, bakım ve sadece kodu anlamak kolaylaşır.

Zaman zaman daha hassas taneli testlere izin vermek için korunan özel metotlara rastladım (maruz kalan herkese açık API'dan daha sıkı). Bu, kuraldan ziyade (umarım çok nadir) bir istisna olmalıdır, ancak karşılaşabileceğiniz belirli belirli durumlarda yardımcı olabilir. Ayrıca, genel bir API oluştururken hiç düşünmek istemediğiniz bir şey, bu nadir durumlarda dahili kullanım yazılımı üzerinde kullanabileceğiniz "hile" den fazlası.

Bunu deneyimledim ve acınızı hissettim.

Benim çözümüm şunlardı:

bir monolith inşa etmek gibi testleri tedavi etmeyi bırakın.

Bir takım testler yazdığınızda, bazı işlevleri yerine getirmek için 5 diyelim, tüm bu testleri sürdürmeniz gerekmediğini unutmayın. , özellikle de başka bir şeyin bir parçası olduğunda, .

Örneğin, sık sık var:

• düşük seviye testi 1
• karşılamak için kod
• düşük seviye testi 2
• karşılamak için kod
• düşük seviye testi 3
• karşılamak için kod
• düşük seviye testi 4
• karşılamak için kod
• düşük seviye testi 5
• karşılamak için kod

öyleyse bende var

• düşük seviye testi 1
• düşük seviye testi 2
• düşük seviye testi 3
• düşük seviye testi 4
• düşük seviye testi 5

Şimdi testlerin bir şey var ki o dediğimiz üst düzey işlev (ler) ekleyin Ancak, ben belki şimdi sadece olmak için bu düşük seviyeli testlerini azaltmak mümkün:

• düşük seviye testi 1
• düşük seviye testi 5

Şeytan ayrıntıda gizlidir ve bunu yapabilme yeteneği koşullara bağlı olacaktır.

Güneş dünyanın etrafında mı yoksa dünyanın etrafında güneşin etrafında mı döner? Einstein'a göre cevap evet ya da her iki model de sadece bakış açısına göre farklılık gösterdiğinden, aynı şekilde kapsülleme ve teste dayalı gelişim, sadece sandığımız için çelişkili olduğu için. Burada Galileo ve papa gibi oturup, birbirimize hakaret etmekle uğraşıyoruz: aptal, özel yöntemlerin de test etmesi gerektiğini görmüyor musun? heretic, kapsülleme kırma! Aynı şekilde, hakikatin düşündüğümüzden daha büyük olduğunu fark ettiğimizde, özel arayüzler için yapılan testlerin kapsüllenmesi gibi bir şey deneyebilir miyiz ki, genel arayüzler için yapılan testler de enkapsülasyonu bozmaz.

Bunu deneyin: iki yöntem ekleyin, biri girişi olmayan, ancak justs özel test sayısını döndürür, diğeri parametre olarak test numarasını alır ve pass / fail değerini döndürür.