TDD - Birim testi [kapalı]

Şirketim, kodumuzu test etme konusunda oldukça yenidir. Bir süredir TDD ve birim testi hakkında okuyorum ve bunların değerine ikna oldum. Ekibimizi, TDD'nin nasıl programladığımızı öğrenme ve zihniyetimizi değiştirme çabasına değeceğine ikna etmeye çalıştım ama bu bir mücadele. Bu da beni sorularıma getiriyor.

TDD topluluğunda testi ve sonra kodu yazma konusunda çok dindar olan pek çok kişi var (ve onlarla birlikteyim), ancak TDD ile mücadele eden bir ekip için uzlaşma yine de ek faydalar sağlıyor mu?

Kod yazıldıktan sonra (belki de kodu kontrol etmek için bir gereklilik olarak) takıma birim testleri yazmayı başarabilirim ve benim varsayımım, bu birim testlerinin yazılmasında hala değer olduğu yönündedir.

Mücadele eden bir takımı TDD'ye getirmenin en iyi yolu nedir? Ve başarısız olmak, kod yazıldıktan sonra olsa bile birim testleri yazmaya değer mi?

DÜZENLE

Bundan çıkardığım şey, kodlama sürecinde bir yerde birim testine başlamamızın bizim için önemli olduğudur. Ekipte konsepti alan kişiler için, önce TDD'ye doğru ilerlemeye ve test etmeye başlayın. Herkesin katkısı için teşekkürler.

TAKİP ET

Kısa süre önce yeni bir küçük projeye başladık ve ekibin küçük bir kısmı TDD kullandı, geri kalanı kodun ardından birim testleri yazdı. Projenin kodlama kısmını tamamladıktan sonra, koddan sonra birim testlerini yazanlar, TDD kodlayıcılarının daha önce yapılmış ve daha katı kod ile yapıldığını görünce şaşırdılar. Şüphecileri kazanmak için iyi bir yoldu. Önümüzde hala büyüyen birçok acımız var, ancak irade savaşı bitmiş gibi görünüyor. Tavsiye veren herkese teşekkürler!

Ekip TDD'yi uygulamada bocalıyorsa, ancak daha önce Birim Testi oluşturmuyorsa ... daha sonra kodları yazıldıktan sonra Birim Testleri oluşturarak başlayın. Koddan sonra yazılan Birim testleri bile Birim Testlerinin hiç yapılmamasından daha iyidir!

Unit Testing (ve onunla birlikte gelen her şey) konusunda uzman olduklarında, onları önce testleri oluşturmaya ve sonra kodlamaya çalışabilirsiniz.

Kod yazıldıktan sonra yine de birim testleri yazmaya değer. Sadece bazen kodunuz test edilebilir olacak şekilde tasarlanmadığı için genellikle daha zordur ve onu aşırı karmaşık hale getirmiş olabilirsiniz.

Bir takımı TDD'ye getirmenin iyi bir pragmatik yolu, geçiş döneminde veya muhtemelen uzun vadede alternatif "geliştirme sırasında test etme" yöntemini sağlamaktır. Kendilerine doğal görünen kodun TDD bölümlerine teşvik edilmelidirler. Ancak, önce teste yaklaşması zor görünen kod bölümlerinde veya çevik olmayan bir A&D süreci tarafından önceden belirlenmiş nesneleri kullanırken, geliştiricilere kodun küçük bir bölümünü yazma seçeneği verilebilir ve ardından bunu kapsayacak testler yazma seçeneği verilebilir. kodlama ve bu işlemi tekrar etme. Bu kodu yazdıktan hemen sonra bazı kodlar için birim testleri yazmak, hiçbir birim testi yazmamaktan daha iyidir.

Benim düşünceme göre, "önce kod, sonra test et" ile% 50 test kapsamına ve% 100 tamamlanmış bir kitaplığa,% 100 test kapsamına ve TDD ile% 50 tamamlanmış bir kitaplığa sahip olmak daha iyidir. Bir süre sonra, geliştiricileriniz yazdıkları tüm publickodlar için testler yazmayı umarım eğlenceli ve eğitici bulacaklar , böylece TDD, geliştirme rutinlerine gizlice girecektir.

Bunu bir takvimde okudum: "En üst düzeyde uygulanan her kural, saçma ve hatta tehlikeli hale gelir." Bu yüzden benim önerim bu konuda dindar olmamak. Ekibinizin her üyesi, test etme konusunda "doğru" hissettikleri arasında bir denge bulmalıdır. Bu şekilde, ekibinizin her üyesi en üretken olacaktır ("neden bu sti **** testi yazmam gerekiyor?" Diye düşünmek yerine).

Bu yüzden bazı testler hiç yoktan iyidir, koddan sonraki testler birkaç testten daha iyidir ve koddan önce yapılan testler sonradan daha iyidir. Ancak her adımın kendine özgü değerleri vardır ve küçük adımlara bile kaşlarını çatmamalısınız.

TDD tasarımla ilgilidir! Bu nedenle, kullanırsanız, kodunuzun test edilebilir bir tasarımına sahip olduğunuzdan emin olacaksınız ve testlerinizi yazmayı kolaylaştıracaksınız. Kod yazıldıktan sonra testler yazarsanız, yine de değerlidirler ancak IMHO muhtemelen test edilebilir bir tasarımınız olmayacağı için zaman kaybedeceksiniz.

Ekibinizi TDD'yi benimsemeye ikna etmeye çalışmanız için size verebileceğim bir öneri , Mary Lynn Manns ve Linda Rising tarafından yazılan Korkusuz Değişim: Yeni Fikirlere Giriş Kalıpları'nda açıklanan tekniklerden bazılarını kullanmaktır .

Testte IMO'dan yeniyse, önceden yazılmış kodu test etmeye başlayın ve yavaşça önce test yazmaya başlayın. TDD'yi öğrenmeye çalışan ve birim testinde yeni biri olarak, koddan önce testler yazmak için tam bir 180 yapmak ve zihniyetimi değiştirmek biraz zor buldum, bu yüzden benim aldığım yaklaşım bir çeşit 50-50 karışımı. ; Kodun tam olarak neye benzeyeceğini bildiğimde, kodu yazacağım ve ardından doğrulamak için bir test yazacağım. Tamamen emin olmadığım durumlar için, o zaman bir testle başlayıp geriye doğru çalışacağım.

Ayrıca, testleri tatmin etmek için kod yazmak yerine, kodu doğrulamak için testler yazmanın yanlış olmadığını da unutmayın. Ekibiniz TDD rotasına gitmek istemiyorsa, onu onlara zorlamayın.

Kod yazıldıktan sonra (belki de kodu kontrol etmek için bir gereklilik olarak) takıma birim testleri yazmayı başarabilirim ve benim varsayımım, bu birim testlerinin yazılmasında hala değer olduğu yönündedir.

Test edilen birim kodda değer olduğu konusunda hiç şüphe yok (testlerin ne zaman yazıldığına bakılmaksızın) ve "Bitti Tanımı" na "kod birim test edilir" i ekledim. İnsanlar test ettikleri sürece TDD kullanabilir veya kullanmayabilirler.

Sürüm kontrolü ile ilgili olarak, birim test edilmiş bir politika ile " geliştirme dalları " kullanmayı seviyorum (yani kod derler ve oluşturur, tüm birim testleri geçer). Özellikler yapıldığında, geliştirme dallarından gövdeye yayınlanırlar. Başka bir deyişle, ana şube " Bitti şubedir " (bagajda çöp yok!) Ve daha katı olan ve "test edilen birimden" daha fazla şey içeren sevk edilebilir bir politikası (herhangi bir zamanda serbest bırakılabilir) vardır.

Bu, ekibinizin inanmaya başlamadan önce kendi başarılarına sahip olması gereken bir şeydir. Önem veren herkes için nUnit epifanim hakkında söyleneceğim:

Yaklaşık 5 yıl önce bir proje üzerinde çalışırken nUnit'i keşfettim. V1.0'ı neredeyse tamamlamıştık ve sadece bu yeni aracı denemek için birkaç test oluşturdum. Çok fazla hatamız vardı (tabii ki!) Çünkü yeni bir takımdık, sıkı bir son teslim tarihine sahiptik, yüksek beklentiler (tanıdık geliyor mu?) Vs. Her neyse, 1.0'a girdik ve 1.1'e başladık. Ekibi biraz yeniden düzenledik ve bana atanan 2 geliştiricim var. Onlar için 1 saatlik bir demo yaptım ve yazdığımız her şeyin onunla bir test vakası olması gerektiğini söyledim. 1.1 geliştirme döngüsü boyunca ekibin geri kalanının "gerisinde" koştuk çünkü daha fazla kod yazıyorduk, birim testleri. Sonunda daha fazla çalıştık ama işte karşılığını - sonunda test etmeye başladığımızda kodumuzda tam olarak 0 hata vardı. Diğer herkesin hatalarını ayıklamasına ve onarmasına yardımcı olduk. Ölümden sonra, hata sayıları ortaya çıktığında,

Başarıya giden yolu test edebileceğini düşünecek kadar aptal değilim ama konu birim testleri olduğunda gerçek bir inancıyım. Proje nUnit'i benimsedi ve kısa sürede tüm .Net projelerinde 1 başarı ile şirkete yayıldı. V1.1 sürümümüzün toplam süresi 9 dev haftaydı, bu nedenle kesinlikle bir gecede başarı OLMADI. Ancak uzun vadede, projemiz ve çözüm ürettiğimiz şirket için başarılı oldu.

Hiç şüphe yok ki, test etmenin (İlk, Bir Zaman ve hatta Sonra) pastırmanızı koruyacağı ve üretkenliğinizi ve güveninizi artıracağı. Benimsemenizi tavsiye ederim!

Ben de benzer bir durumdaydım, çünkü "çaylak" bir geliştirici olduğum için, ekip projesi üzerinde çalışırken, yapıyı bozan bir katkı yüzünden sık sık hayal kırıklığına uğradım. Suçlu muyum, hatta bazı durumlarda kimi suçlayacağımı bilmiyordum. Ama aynı şeyi geliştirici arkadaşlarıma yaptığım için daha çok endişeliydim. Bu farkındalık daha sonra bazı TDD stratejilerini benimsemeyi motive etti. Ekibimiz saçma oyunlara ve kurallara başladı, tüm testleriniz geçene kadar eve gidemezsiniz ya da test olmadan bir şey gönderirseniz, o zaman herkese "bira / öğle yemeği / vb." Satın almanız gerekir ve bu TDD'yi daha eğlenceli hale getirdi.

Birim testinin en kullanışlı yönlerinden biri, halihazırda çalışan kodun sürekli doğruluğunu sağlamaktır. İstediğiniz zaman yeniden düzenleme yapabildiğiniz zaman, bir IDE'nin size derleme zamanı hatalarını hatırlatmasına izin verin ve ardından testlerinizin olası çalışma zamanı hatalarını tespit etmesine izin vermek için bir düğmeyi tıklayın - bazen daha önce önemsiz kod bloklarına ulaşırsanız, o zaman ekibinizi bulacağınızı düşünüyorum TDD'yi takdir etmeye başladım. Dolayısıyla, mevcut kodu test etmekle başlamak kesinlikle faydalıdır.

Ayrıca, açık konuşmak gerekirse, TDD ile başlamaktan ziyade yazılı kodu test etmeye çalışarak test edilebilir kod yazma hakkında daha fazla şey öğrendim. Hem nihai hedefi gerçekleştirecek hem de teste izin verecek sözleşmeler düşünmeye çalışıyorsanız, ilk başta çok soyut olabilir. Ancak koda bakıp "Buradaki bu tekil bağımlılık enjeksiyonunu tamamen bozuyor ve bunu test etmeyi imkansız hale getiriyor" diyebildiğinizde, hangi kalıpların test hayatınızı kolaylaştırdığına dair bir takdir geliştirmeye başlıyorsunuz.

Peki, önce testler yazmazsanız, "Test Driven" değildir, sadece testtir. Kendi içinde faydaları vardır ve eğer zaten bir kod tabanı ekleme testine sahipseniz, TDD olmasa da sadece test olsa bile kesinlikle faydalıdır.

İlk olarak test yazma, kodun yazmadan önce ne yapması gerektiğine odaklanmakla ilgilidir. Evet, bunu yapan bir test de alıyorsunuz ve bu iyi, ancak bazıları bunun en önemli nokta olmadığını bile iddia edebilir.

Yapacağım şey takımı TDD kullanarak bunun gibi oyuncak projeleri konusunda eğitmek (bkz. Kodlama Dojo, Katas) (eğer deneyimli TDD programcılarını böyle bir atölyeye katılmaya ikna edebilirseniz daha da iyi olurdu). Faydaları gördüklerinde gerçek proje için TDD'yi kullanacaklar. Ama bu arada onları zorlamayın, doğru yapmayacaklarının faydasını görmezler.

Kod yazmadan önce tasarım oturumlarınız varsa veya bir tasarım belgesi hazırlamanız gerekiyorsa, bir oturumun somut sonucu olarak Birim Testleri ekleyebilirsiniz.

Bu, daha sonra kodunuzun nasıl çalışması gerektiğine dair bir şartname olarak hizmet edebilir. İnsanların belirli senaryolarda bir şeyin nasıl çalışması gerektiği ve ne yapması gerektiği hakkında konuşmasını sağlamak için tasarım oturumunda eşleştirmeyi teşvik edin. Örneğin, boş bir argüman verildiğinde herkes ne yapacağını bilmesi için onlar için açık test durumları olan uç durumlar nelerdir.

Bir kenara ancak BDD de ilgi çekici olabilir

TDD'nin daha az kod yazılmasına yol açtığı bir veya iki örnek göstererek biraz çekişme bulabilirsiniz - çünkü yalnızca testi geçmek için gereken kodu yazarsınız, altın plaka veya YAGNI ile meşgul olma cazibesine direnmek daha kolaydır. Yazmadığınız kodun bakımı, yeniden düzenlenmesi vb. Gerekmez, bu nedenle TDD konseptinin satılmasına yardımcı olabilecek "gerçek bir tasarruf" dur.

Değeri zaman, maliyet, kod ve tasarruf edilen hatalar açısından net bir şekilde gösterebilirseniz, satışın daha kolay olduğunu görebilirsiniz.

JUnit test sınıfları oluşturmaya başlamak, başlamanın yoludur, mevcut kod için başlamanın tek yolu budur. Deneyimlerime göre, mevcut kod için test sınıfları oluşturmak çok yararlıdır. Yönetim bunun çok fazla zaman harcayacağını düşünürse, yalnızca ilgili sınıfta bir hata bulunduğunda veya temizlemeye ihtiyaç duyulduğunda test sınıfları yazmayı önerebilirsiniz.

Bakım süreci için, ekibi hattan geçirme yaklaşımı, hataları düzeltmeden önce yeniden üretmek için JUnit testleri yazmak olacaktır.

• hata bildirildi
• gerekirse JUnit test sınıfı oluşturun
• hatayı yeniden üreten bir test ekleyin
• kodunu düzelt
• mevcut kodun hatayı yeniden oluşturmadığını göstermek için testi çalıştırın

Hataları bu şekilde "belgeleyerek" bu hataların daha sonra tekrar ortaya çıkmasını önleyeceğini açıklayabilirsiniz. Bu, ekibin hemen deneyimleyebileceği bir avantajdır.

Bunu birçok kuruluşta yaptım ve TDD'yi başlatmanın en iyi yolunun çift programlamayı kurmak olduğunu buldum. Eğer TDD'yi bilen birine güvenebileceğiniz başka biri varsa, o zaman ikiniz ayrılabilir ve TDD'yi kullanarak bazı eşleştirilmiş programlama yapmak için diğer geliştiricilerle eşleşebilirsiniz. Aksi takdirde, bunu ekibin geri kalanına sunmadan önce size yardımcı olacak birini eğitmezdim.

Birim testi ve özellikle de TDD ile ilgili en büyük engellerden biri, geliştiricilerin bunu nasıl yapacaklarını bilmemeleri, dolayısıyla bunun zamanlarına nasıl değeceğini görememeleridir. Ayrıca ilk başladığınızda, çok daha yavaştır ve fayda sağlamıyor gibi görünmektedir. Sadece bunda iyi olduğunuzda size gerçekten fayda sağlıyor. Eşleştirilmiş programlama oturumları oluşturarak, geliştiricilerin bunu hızlı bir şekilde öğrenmesini ve daha çabuk başarılı olmasını sağlayabilirsiniz. Ek olarak, birlikte çalıştıkça bundan anında fayda görebilecekler.

Bu yaklaşım geçmişte benim için birçok kez işe yaradı.

TDD'nin faydalarını keşfetmenin güçlü bir yolu, belki de performans nedenlerinden ötürü, bazı mevcut işlevselliklerin önemli ölçüde yeniden yazılmasıdır. Mevcut kodun tüm işlevlerini kapsayan iyi bir iş çıkaran bir dizi test oluşturarak, bu, daha sonra kalbinizin içeriğini, değişikliklerinizin güvende olduğuna dair tam bir güvenle yeniden düzenleme konusunda size güven verir.

Bu durumda, uygulama detaylarını test eden tasarım veya sözleşme birimi testlerinin burada uygun olmayacağından bahsediyorum. Ancak yine de TDD, uygulamadan önce yazılmaları gerektiği için uygulamayı tanım gereği test edemez.

TDD, geliştiricilerin daha iyi kod üretmek için kullanabilecekleri bir araçtır. Test edilebilir kod yazma alıştırmasının en az testlerin kendisi kadar değerli olduğunu hissediyorum. Test amacıyla IUT'yi (Test Altındaki Uygulama) ayırmak, kodunuzu ayırmanın yan etkisine sahiptir.

TDD herkes için değildir ve bir takımın bunu yapmayı seçmesini sağlayacak hiçbir sihir yoktur. Risk, neyin test edilmeye değer olduğunu bilmeyen birim test yazarlarının, organizasyonunuzdaki TDD şüphecileri için önemli olan çok sayıda düşük değerli test yazmasıdır.

Genelde otomatik Kabul Testlerini tartışılmaz hale getiririm, ancak geliştiricilerin TDD'yi kendilerine uygun şekilde benimsemelerine izin veririm . Tecrübeli TDDer'larımın geri kalanı eğitmesini / danışmanlığını ve yararlılığını aylarca bir süre boyunca örneklerle "kanıtlamasını" sağladım.

Bu teknik olduğu kadar sosyal / kültürel bir değişimdir.