Üzerinde çalıştığım ekipte birim testini geliştirme sürecine entegre etmek için çalışıyorum ve bazı şüpheciler var. Şüpheci geliştiricileri, Birim Testinin değeri ekibine ikna etmenin bazı iyi yolları nelerdir? Özel durumumda, işlevsellik veya sabit hatalar ekledikçe Birim Testleri ekliyor olacağız. Maalesef kod tabanımız kolay testlere yetkin değil.
Ofisimizde her gün böyle bir şeye giden bir değişim var:
"Dostum, ben sadece ünite testlerini seviyorum, bir şeylerin çalışması için bir sürü değişiklik yapabildim ve daha sonra testi tekrar yaparak hiçbir şeyi kırmadığımı doğruladım ..."
Detaylar günlük olarak değişiyor, ama duygular değişmiyor. Birim testleri ve teste dayalı geliştirme (TDD), o kadar çok gizli ve kişisel faydaya sahip olmasının yanı sıra, bir başkasına kendileri yapana kadar gerçekten açıklayamayacağınız belirgin özelliklere de sahiptir.
Ama, bunu görmezden gelmek, işte benim girişimim!
Birim Testleri, kodda hızlıca büyük değişiklikler yapmanızı sağlar. Şimdi çalıştığını biliyorsunuz çünkü testleri yaptınız, yapmanız gereken değişiklikleri yaptığınızda, testleri tekrar çalıştırmalısınız. Bu saatlerce tasarruf sağlar.
TDD, kodlamanın ne zaman durması gerektiğini anlamanıza yardımcı olur. Testleriniz şu an için yeterince şey yaptığınıza güveniyor ve ince ayarlamayı bırakıp bir sonraki şeye geçebiliyor.
Testler ve kod daha iyi kod elde etmek için birlikte çalışır. Kodunuz kötü olabilir/adamcağız. TESTİNİZ kötü olabilir/adamcağız. TDD'de, her ikisi de kötü olma/buggy'nin düşük olma olasılığına güveniyorsunuz. Genellikle, düzeltilmesi gereken test olur, ancak bu hala iyi bir sonuçtur.
TDD, kodlama kabızlığına yardımcı olur. İleride büyük ve göz korkutucu bir eserle karşı karşıya kaldığınızda testler hızlı bir şekilde hareket etmenizi sağlayacaktır.
Birim Testleri, üzerinde çalıştığınız kodun tasarımını gerçekten anlamanıza yardımcı olur. Bir şeyi yapmak için kod yazmak yerine, kodu tabi tuttuğunuz tüm koşulları ve bundan hangi çıktıları beklediğinizi açıklayarak başlıyorsunuz.
Birim Testleri size anında görsel geribildirim verir, hepimiz yaptığımız zaman tüm bu yeşil ışıkların hissini seviyoruz. Çok tatmin edici. Ayrıca, bir kesinti sonrasında kaldığınız yerden çıkmak çok daha kolaydır, çünkü nereye gideceğinizi görebilirsiniz - düzeltilmesi gereken bir sonraki kırmızı ışık.
Popüler inanç birimine yapılan testlerin aksine, iki kat fazla kod yazmak veya daha yavaş kodlamak anlamına gelmez. Testten sonra kodlamadan daha hızlı ve sağlamdır. Test kodunun kendisi genellikle nispeten önemsizdir ve yaptığınız şeye büyük bir ek yük getirmez. Bu sadece bunu yaparken inanacağınız bir :)
"Kusursuz testler, sık sık yapılanlar, asla yazılı olmayan mükemmel testlerden çok daha iyi" diyen Fowler’dı. Bunu, kod kapsamımın geri kalanı tamamen eksik olsa bile, en faydalı olacağını düşündüğüm testler yazma izni verdiğimi yorumluyorum.
İyi birim testleri, ne yapılması gerektiğini belgelemek ve tanımlamak için yardımcı olabilir
Ünite testleri, kodun yeniden kullanımı konusunda yardımcı olur. Her iki kodunuzu da ve testlerinizi yeni projenize taşıyın. Testler tekrar çalışana kadar kodu değiştirin.
Yaptığım birçok iş Birim Testini iyi yapmıyor (web uygulaması kullanıcı etkileşimleri vb.), Ancak bu mağazada hepimiz virüs bulaşmış testler yapıyoruz ve testlerimizi bağladığımızda mutluyuz. Bu yaklaşımı yeterince tavsiye edemiyorum.
Birim testi spor salonuna gitmek gibi bir şey. Sizler için iyi olduğunu biliyorsunuz, tüm argümanlar mantıklı, bu yüzden çalışmaya başlıyorsunuz. Harika bir başlangıç Rush var, ancak birkaç gün sonra belaya değip değmeyeceğini merak etmeye başlarsınız. Giysilerinizi değiştirmek ve bir hamster çarkında koşmak için günün bir saatini alıyorsunuz ve gerçekten bacaklarınız ve kollarınızdan başka bir şey kazandığınızdan emin değilsiniz.
Sonra, belki bir veya iki hafta sonra, tıpkı acı çekerken, Büyük Bir Son Tarih yaklaşmaya başlar. Her uyanış saatini "işe yarar" bir iş yapmak için harcamanız gerekir, böylece spor salonuna gitmek gibi yabancı şeyler de kesersiniz. Alışkanlıktan düşersiniz ve Büyük Son Tarih bittiğinde, ilk kareye dönersiniz. Spor salonuna geri dönmeyi başarırsan, ilk gittiğin zamanki gibi acı çekiyorsun.
Yanlış bir şey yapıp yapmadığını görmek için biraz okuma yapıyorsun. Egzersizin erdemlerini hayrete düşüren tüm zinde, mutlu insanlara karşı biraz irrasyonel kibarlık hissetmeye başlarsınız. Çok fazla ortak noktanız olmadığını biliyorsunuz. Spor salonuna gitmek için yoldan 15 dakika uzaklaşmaları gerekmez; binalarında bir tane var. Egzersizin yararları hakkında kimseyle tartışmak zorunda değiller; bu sadece herkesin yaptığı ve önemli olarak kabul ettiği bir şey. Büyük Bir Son Tarih yaklaştığında, alıştırmanın patronunuzun sizden yemeyi bırakmanızı isteyeceğinden daha fazla gereksiz olmadığı söylenmedi.
Sorunuzu cevaplamak için, Ünite Testi genellikle çabaya değer, ancak gereken efor miktarı herkes için aynı olmayacak. Eğer Ünite Testi eğer sizin için muazzam miktarda çaba gerektirebilir aslında değer kodu kalitesine sahip olmayan bir şirkette spagetti kod tabanı ile çalışıyor. (Bir çok yönetici Unit Testing'in övgülerini söyleyecektir, ancak bu önemli olduğunda buna katlanacakları anlamına gelmez.)
İşinize Birim Testini uygulamaya çalışıyorsanız ve beklediğiniz tüm güneş ışığını ve gökkuşağını göremiyorsanız, kendinizi suçlamayın. Ünite Testi'nin gerçekten sizin için çalışmasını sağlamak için yeni bir iş bulmanız gerekebilir.
İkna etmenin en iyi yolu ... bir hatayı bulmak, bunun için bir birim testi yazmak, hatayı düzeltmek.
Bu özel hatanın bir daha ortaya çıkması pek olası değildir ve testinizde bunu kanıtlayabilirsiniz.
Bunu yeterince yaparsan, diğerleri çabucak yakalanır.
thetalkingwalnut soruyor:
Şüpheci geliştiricileri, Birim Testinin değeri ekibine ikna etmenin bazı iyi yolları nelerdir?
Buradaki herkes, neden birim test etmenin iyi olduğu konusunda mavi bir çok nedene dayanacak. Ancak, birisini bir şeye ikna etmenin en iyi yolunun, argümanlarını dinlemek ve onu nokta nokta adreslemektir. Endişelerini dile getirmelerine yardımcı olurlarsa dinler ve her birine hitap edebilir ve belki de onları kendi bakış açınıza dönüştürebilirsiniz (ya da en azından onları ayakta durmalarına gerek kalmadan bırakabilirsiniz). Kim bilir? Belki de birim testlerin sizin durumunuza neden uygun olmadığına sizi ikna edeceklerdir. Muhtemel değil ama mümkün. Belki de argümanlarını birim testlerine karşı gönderirseniz, karşı sayımların belirlenmesine yardımcı olabiliriz.
Argümanın iki tarafını da dinlemek ve anlamak önemlidir. İnsanların kaygıları gözetilmeksizin ünite testlerini çok gayretli bir şekilde benimsemeye çalışırsanız, dini bir savaşla (ve muhtemelen gerçekten değersiz ünite testleriyle) sonuçlanır. Yavaş yavaş benimser ve en düşük maliyet için en fazla faydayı göreceğiniz yere uygulayarak başlarsanız, birim testlerinin değerini gösterebilir ve insanları daha iyi ikna etme şansınız olabilir. Bunun göründüğü kadar kolay olmadığını fark ediyorum - ikna edici bir argüman oluşturmak için genellikle biraz zaman ve dikkatli ölçümler gerektiriyor.
Birim testleri, diğerleri gibi bir araçtır ve faydaların (böcekleri yakalamanın) maliyetleri (ağır basan çaba) daha ağır basacağı şekilde uygulanmalıdır. Mantıklı değillerse/kullandıklarında bunları kullanmayın ve bunların yalnızca araç cephaneliğinizin bir parçası olduğunu unutmayın (örneğin denetimler, iddialar, kod analizörleri, resmi yöntemler vb.). Geliştiricilerime söylediğim şudur:
Neden gerekli olmadığına dair iyi bir tartışmaya sahiplerse (örneğin, buna değer veremeyecek kadar basit veya buna değmeyecek kadar zor) ve yöntemin başka şekilde nasıl doğrulanacağını (ör. İnceleme, iddialar) bir yöntem için test yazmayı atlayabilirler. , biçimsel yöntemler, etkileşimli/entegrasyon testleri). Denetimler ve resmi provalar gibi bazı doğrulamaların zaman içinde yapıldığı ve üretim kodu her değiştiğinde tekrarlanması gerektiği düşünülmelidir, oysa birim testleri ve iddiaları regresyon testi olarak kullanılabilir (bir kez yazılır ve daha sonra tekrar tekrar uygulanır). ). Bazen onlarla aynı fikirdeyim, ancak daha sıklıkla bir yöntemin ünite testi için gerçekten çok basit veya çok zor olup olmadığını tartışacağım.
Bir geliştirici, bir yöntemin başarısız olmak için çok basit göründüğünü savunuyorsa, bunun için basit bir 5 satırlık ünite testi yazmak için gereken 60 saniyeyi almaya değmez mi? Bu 5 kod satırı her gece çalışacak (gece yaparsınız, doğru mu?) Gelecek yıl veya daha fazlası için ve sadece bir kez bile tanımlamak için 15 dakika veya daha uzun süren bir problemi yakalamak için olsa bile çabaya değer ve hata ayıklama. Ayrıca, kolay ünite testlerini yazmak, geliştiricinin iyi görünmesini sağlayan ünite testlerinin sayısını artırır.
Öte yandan, bir geliştirici bir yöntemin birim test yapmak için çok zor göründüğünü (gerekli çabaya değmeyecek şekilde) savunuyorsa, belki de bu, kolay parçaların test edilmesi için yöntemin bölünmesi veya yeniden yapılandırılması gerektiğinin iyi bir göstergesidir. Genellikle, bunlar singletons gibi olağandışı kaynaklara, şimdiki zamana veya veritabanı sonuç kümesi gibi harici kaynaklara dayanan yöntemlerdir. Bu yöntemlerin genellikle kaynağı alan bir yöntem (örneğin, getTime () olarak adlandırılır) ve kaynağı argüman olarak alan bir yöntem (örneğin, zaman damgasını parametre olarak alır) yeniden yapılandırılması gerekir. Kaynak alan yöntemi test etmeyi atlamalarına izin veriyorum ve bunun yerine, şimdi kaynağı argüman olarak alan yöntem için bir birim testi yazıyorlar. Genelde bu, ünite testi yazmayı çok daha basit ve dolayısıyla yazmaya değer kılar.
Geliştiricinin birim testlerinin ne kadar kapsamlı olması gerektiğine bir "kumda çizgi" çizmesi gerekir. Gelişimin ilerleyen saatlerinde, ne zaman bir hata bulduğumuzda, daha kapsamlı birim testlerinin sorunu yakalayıp yakalamayacağına karar vermeleri gerekir. Eğer öyleyse ve bu tür böcekler tekrar tekrar ortaya çıkarsa, "satırı" ileride daha kapsamlı birim testleri yazmaya yönlendirmek zorundadırlar (mevcut hata için birim testini eklemek veya genişletmekle başlayarak). Doğru dengeyi bulmaları gerekiyor.
Birim testlerinin gümüş bir mermi olmadığını ve orada çok fazla birim testi gibi bir şey olduğunu gerçekleştirmek önemlidir. İşyerimde ne zaman bir ders çıkarırsak, kaçınılmaz olarak “daha fazla birim test yazmamız gerekir” diye duydum. Yönetim, “birim testleri” == “iyi” olduğu için kafalarına çarpıldığı için anlaşmaya başlamıyor.
Bununla birlikte, "daha fazla birim testi" nin etkisini anlamamız gerekir. Bir geliştirici haftada sadece ~ N kod satırı yazabilir ve bu kodun yüzde kaçının birim test kodu ve üretim kodu olması gerektiğini çözmeniz gerekir. Bir gevşek işyeri, birim testler olarak kodun% 10'una ve üretim kodu olarak kodun% 90'ına sahip olabilir; bu da, çok (çok hatalı olsa da) özellikleri olan bir ürünle sonuçlanabilir (MS Word'ü düşünün). Öte yandan,% 90 birim testine ve% 10 üretim koduna sahip sıkı bir mağazada çok az özellik içeren sağlam bir ürün olacaktır ("vi" düşünün). Bu son ürün kilitlenmesiyle ilgili raporları asla duyamazsınız, ancak bunun, ürünün kod kalitesiyle ilgili olduğu kadar iyi satmama ile ilgisi vardır.
Daha da kötüsü, belki de yazılım geliştirmedeki tek kesinlik "değişimin kaçınılmaz" olduğudur. Sıkı mağazada (% 90 birim testi /% 10 üretim kodu) tam 2 özelliğe sahip bir ürün yarattığını (üretim kodunun% 5'inin == 1 özellik olduğu varsayılarak) oluşturduğunu varsayalım. Müşteri gelip özelliklerin 1'ini değiştirirse, bu değişiklik kodun% 50'sini (birim testlerin% 45'ini ve üretim kodunun% 5'ini) çöker. Laks mağazasında (% 10 birim testi /% 90 üretim kodu), hiçbiri iyi çalışmayan 18 özellikli bir ürün bulunur. Müşterileri, özelliklerinin 4'ünün gereksinimlerini tamamen yeniliyor. Değişim 4 kat daha büyük olmasına rağmen, kod tabanının sadece yarısı çöpe atıldı (~% 25 = ~% 4.4 ünite testleri + üretim kodunun +% 20'si).
Demek istediğim, çok az ve çok fazla birim testi arasındaki dengeyi anladığınızı, aslında sorunun her iki tarafından da düşündüğünüzü anlamanız gerektiğini söylemelisiniz. Akranlarınızı ve/veya yönetiminizi bu konuda ikna edebiliyorsanız, güvenilirlik kazanırsınız ve belki de onları kazanma şansınız daha yüksektir.
Birkaç kez test birimiyle oynamıştım ve hala durumum için verilen çabaya değeceğine inanıyorum.
Mantığın çoğunun veritabanında veri oluşturmayı, almayı veya güncellemeyi içerdiği web siteleri geliştiriyorum. Birim sınama amacıyla veritabanını "alay etmeye" çalıştığımda, çok dağınık ve biraz anlamsız görünüyordu.
İş mantığı etrafında birim testleri yazdığımda, uzun vadede bana hiçbir zaman yardımcı olmadı. Çünkü büyük ölçüde sadece projeler üzerinde çalışıyorum, üzerinde çalıştığım bir şeyden hangi kod alanlarının etkilenebileceğini sezgisel olarak anlıyorum ve bu alanları manuel olarak test ediyorum. Müşterime mümkün olan en kısa sürede bir çözüm sunmak istiyorum ve birim testi genellikle zaman kaybı gibi görünüyor. El ile yapılan testleri listeler ve kendim yürüterek ilerlerken onları işaretlerim.
Bir geliştirici ekibi bir proje üzerinde çalışırken ve birbirlerinin kodunu güncellerken yararlı olabileceğini görebiliyorum, ancak o zaman bile geliştiricilerin kalitesi yüksekse iyi bir iletişim ve iyi yazılmış bir kodun yeterli olacağını düşünüyorum. .
Ünite testleri ile ilgili harika bir şey, kodunuzun nasıl davranması gerektiği konusunda dokümantasyon işlevi görmeleridir. İyi testler bir referans uygulaması gibidir ve ekip arkadaşları kendi kodlarını nasıl kullanacaklarını görmek için onlara bakabilir.
Birim testi, başlangıçtaki yatırıma değer. Birkaç yıl önce birim testini kullanmaya başladığımdan beri, bazı gerçek faydalar buldum:
Kod parçacıkları, test oluşturma ek yükünün azaltılmasında çok yardımcı olabilir. Birkaç saniye içinde bir sınıf anahattı ve ilgili birim testi armatürü oluşturulmasını sağlayan pasajlar oluşturmak zor değildir.
Mümkün olduğunca az test etmelisiniz!
yani, niyetini ortaya çıkarmak için yeterince birim test yazmalısın. Bu genellikle üzerinde parlıyor. Birim testi size maliyeti. Değişiklikler yaparsanız ve testleri değiştirmek zorunda kalırsanız, daha az çevik olursunuz. Ünite testlerini kısa ve tatlı tutun. O zaman çok değerleri var.
Sık sık, asla kırılmayacak, büyük ve sakar, çok fazla değer sunamayacak çok sayıda test görüyorum.
Bunu diğer cevapların hiçbirinde görmedim, ancak fark ettiğim bir şey de çok daha hızlı hata ayıklayabilirdim. Sabitleme kodunuzu elde etmek için yalnızca doğru bir adımlar dizisi ile uygulamanızla uğraşmanıza gerek yok, yalnızca bir mantıksal hata yaptığınızı bulmak ve hepsini tekrar yapmanız gerekir. Birim testiyle, doğrudan hata ayıklama yaptığınız koda adım atabilirsiniz.
[Yukarıda göremediğim bir noktaya değindim]
"Herkes birim testleri, mutlaka farkına varmazlar - FACT"
Bir düşünün, belki bir dizgeyi ayrıştırmak ve yeni satır karakterlerini kaldırmak için bir işlev yazarsınız. Yeni başlayan bir geliştirici olarak, Main () 'da uygulayarak komut satırından birkaç vaka geçirirsiniz veya görsel bir ön ucu bir düğme ile birleştirirsiniz, işlevinizi birkaç metin kutusuna ve bir düğmeye bağlar ve ne oluyor.
Bu, ünite testidir - temel ve hatalı bir şekilde bir araya getirildi, ancak kod parçasını birkaç durum için test ettiniz.
Daha karmaşık bir şey yazıyorsun. Birkaç üniteyi attığınızda (ünite testi) hatalar atıyor ve koda hata ayıklıyor ve izini sürüyorsunuz. Değerlere, ilerledikçe bakar ve doğru mu yanlış mı olduğuna karar verirsiniz. Bu bir dereceye kadar ünite testidir.
Buradaki birim sınama, gerçekten bu davranışı alıp yapılandırılmış bir düzende biçimlendirir ve bu sınamaları kolayca yeniden yürütebilmeniz için kurtarır. Manuel olarak test etmek yerine "uygun" bir birim test durumu yazarsanız, aynı miktarda zaman alır veya belki de deneyiminiz azalır ve tekrar tekrar tekrar etmeye hazır hale gelirsiniz
Yıllarca, insanları kodları için birim testi yazmaları gerektiğine ikna etmeye çalıştım. Testleri ilk önce (TDD'de olduğu gibi) veya işlevselliği kodladıktan sonra yazıp yazmadıklarını, kod için birim test etmenin tüm faydalarını her zaman açıklamaya çalıştım. Neredeyse hiç kimse benimle aynı fikirde değildi. Açık olan bir şeyle aynı fikirde olamazsınız ve herhangi bir akıllı kişi birim testi ve TDD'nin faydalarını görecektir.
Birim testiyle ilgili sorun, davranışsal bir değişiklik gerektirmesi ve insanların davranışlarını değiştirmek çok zor olmasıdır. Kelimelerle, seninle aynı fikirde olacak birçok insan olacak, ama işlerini yapma biçiminde pek fazla değişiklik görmeyeceksin.
İnsanları yaparak ikna etmek zorundasın. Kişisel başarınız, sahip olabileceğiniz tüm argümanlardan daha fazla insanı etkileyecektir. Sadece ünite testinden veya TDD'den bahsetmediğinizi görüyorlarsa, ama vaaz ettiğiniz şeyi yapıyorsunuz ve başarılısınız, insanlar sizi taklit etmeye çalışacaklar.
Ayrıca liderlik rolü üstlenmelisiniz, çünkü hiç kimse ilk defa birim testi yapmaz, bu yüzden nasıl yapılacağı, onlara nasıl yol göstereceği ve onlara uygun araçları koçluk yapmanız gerekebilir. İlk testlerini yazarken onlara yardım edin, kendi yazdıkları testleri gözden geçirin ve kendi deneyimleriniz aracılığıyla öğrendiğiniz püf noktaları, deyimler ve kalıpları gösterin. Bir süre sonra, faydaları kendi başlarına görmeye başlayacaklar ve birim testlerini veya TDD'yi araç kutularına dahil etme davranışlarını değiştirecekler.
Gece boyunca değişiklikler olmayacak, ama biraz sabırla amacına ulaşabilirsin.
Teste dayalı geliştirmenin çoğu zaman anlatıldığı önemli bir bölümü, test edilebilir kodun yazılmasıdır. İlk başta bir çeşit uzlaşma gibi gözüküyor, ancak test edilebilir kodun sonuçta modüler, sürdürülebilir ve okunabilir olduğunu da keşfedeceksiniz. Hala insanları ikna etmek için yardıma ihtiyacınız varsa this , birim testinin avantajları hakkında güzel ve basit bir sunumdur.
Mevcut kod tabanınız ünite testine kendini ödünç vermediyse ve zaten yapım aşamasındaysa, tüm kodunuzu yeniden test etmeye çalışarak çözebildiğinizden daha fazla sorun yaratabilirsiniz, böylece ünite test edilebilir.
Bunun yerine entegrasyon testinizi iyileştirmeye yönelik çaba göstermekte daha iyi olabilirsiniz. Ünite testi yapmadan yazması daha kolay olan birçok kod var ve eğer bir KG bir işlevselliği bir gereksinim belgesine göre doğrulayabiliyorsa, işlem tamamlanmıştır. Onu yükle.
Aklımdaki klasik örnek, bir GridView'a bağlı bir ASPX sayfasına gömülü bir SqlDataReader. Kodun tümü ASPX dosyasında. SQL saklı bir prosedürde. Ünite testi nedir? Sayfa ne yapması gerekiyorsa, gerçekten otomatik olarak birkaç katmana göre yeniden tasarlanmalı ve böylece otomatikleştirecek bir şeyiniz mi olmalı?
Birim testiyle ilgili en iyi şeylerden biri, kodunuzun yaptığınız gibi test etmenin kolaylaşmasıdır. Testler olmadan oluşturulan önceden var olan kod her zaman zordur çünkü ünite testine tabi tutulmaları gerekmediğinden, sınıflar arasında, sınıfınız içinde yapılandırılması zor nesnelerin - bir e-posta gibi yüksek düzeyde bir bağlaşma olması nadir değildir servis referansı gönderme - vb. Ama bunun seni yıkmasına izin verme! Ünite testleri yazmaya başladığınızda genel kod tasarımınızın daha iyi olacağını göreceksiniz ve ne kadar çok test yaparsanız, başvurunuzu bozma veya hatalar ortaya koyma korkusu olmadan üzerinde daha da fazla değişiklik yapma konusunda daha fazla güvende olacaksınız. .
Kodunuzu test etmek için birkaç neden vardır, ancak zaman geçtikçe testten tasarruf ettiğiniz zamanın bunu yapmanın en iyi nedenlerinden biri olduğunu göreceksiniz. Yeni teslim ettiğim bir sistemde, testleri manuel olarak test ederek yaptığımdan çok daha fazla zaman harcayacağım iddialarına rağmen otomatik birim testi yapmakta ısrar ettim. Tüm birim testlerimde, 10 dakikadan daha az bir sürede 400'den fazla test çalışması yaptım ve kodda küçük bir değişiklik yapmak zorunda kaldığımda, kodun hala hata olmadan çalıştığından emin olmam için gereken her şey on dakika. Bu 400'den fazla test vakasını elle yürütmek için harcayacağınız zamanı düşünebiliyor musunuz?
Otomatik testler söz konusu olduğunda - birim testi veya kabul testi olsun - herkes manuel olarak yapabileceğiniz şeyleri kodlamanın boşa harcandığını ve bazen de doğru olduğunu - testlerinizi yalnızca bir kez yapmayı planlıyorsanız düşünüyor. Otomatik sınamanın en iyi yanı, onları çaba sarf etmeden birkaç kez çalıştırabilmenizdir ve ikinci veya üçüncü çalıştırmadan sonra, harcadığınız zaman ve eforu boşa harcarsınız için zaten ödeme yapıldı.
Birim testleri ayrıca, bir parçanın kodunun yeniden düzenlenmesi veya yeniden yazılması konusunda da faydalıdır. İyi bir birim test kapsamınız varsa, güvenle refactor yapabilirsiniz. Ünite testleri olmadan, hiçbir şeyi kırmadığınızdan emin olmak zordur.
Kötü belgelenmiş, korkunç ve büyük bir kod tabanının bakım mühendisi olarak çalışıyorum. Keşke kodu yazanların birim testlerini yazmış olsaydı.
Üretim kodunu her değiştirdiğimde ve güncellediğimde, bazı koşulları göz önünde bulundurmadığım için bir hataya neden olabileceğim için korkuyorum.
Testleri yazarlarsa, kod tabanında değişiklikler yapmak daha kolay ve daha hızlı olurdu (aynı zamanda kod tabanı daha iyi bir durumda olacaktır).
Bence birim testler uzun yıllar sürecek olan api veya çerçeveler yazarken ve orijinal kodlayıcıların dışındaki insanlar tarafından kullanıldığında/değiştirilmesinde/geliştirilmesinde çok faydalı olduğunu düşünüyorum.
Kısacası - evet. Bir noktaya kadar çaba sarf etmeye değer. Testler günün sonunda hala kod ve tipik kod büyümesine benzer şekilde, testlerin sürdürülebilir ve sürdürülebilir olması için en sonunda yeniden yapılandırılması gerekir. Bir ton GOTCHAS var! Birim testine gelince, ama erkek oh erkek oh erkek, hiçbir şey ve demek istediğim NOTHING, bir geliştiriciye, zengin bir birim test setinden daha güvenli değişiklikler yapma yetkisi verir.
Şu anda bir proje üzerinde çalışıyorum .... biraz TDD ve test kurallarına dahil olan iş kurallarımızın çoğuna sahibiz ... şu anda yaklaşık 500 kadar birim testimiz var. Bu geçmiş yineleme veri kaynağımızı ve masaüstü uygulamamızın bu veri kaynağını nasıl etkilediğini yenilemek zorunda kaldım. Birkaç gün sürdü, ne zaman kırdığımı ve neyi düzelttiğimi görmek için birim testlerini sürdürdüm. Bir değişiklik yap; Testlerinizi oluşturun ve çalıştırın; kırdığın şeyi düzelt. Yıkayın, Durulayın, Gerektiği kadar tekrarlayın. Geleneksel olarak günlerce KG ve tekne yükü stresi almış olan bunun yerine kısa ve eğlenceli bir deneyim oldu.
Ön hazırlık, biraz ekstra çaba ve çekirdek özellikler/işlevsellik ile dolaşmaya başlamanız gerektiğinde 10 kat daha fazla ödeme yapar.
Bu kitabı satın aldım - bu bir xUnit Test bilgisinin İncil'i - muhtemelen rafımdaki en çok referans verilen kitaplardan biri ve günlük olarak bakıyorum: link text
Nadiren kendim veya iş arkadaşlarımdan biri birkaç saatini biraz belirsiz hatanın dibine ulaşmak için harcayacak ve böceğin nedeni kodun birim test edilmediği zamanın% 90'ını bulduğunda. Ünite testi, zaman kazanmak için köşeleri kestiği için mevcut değil, ancak bunu ve daha fazla hata ayıklamayı gevşetiyor.
Bir birim testi yazmak için az zaman harcamak, gelecekte hata ayıklamak için zaman kazandırabilir.
“Kod tabanımız kolay test yapmanın kendisini ödünç vermez” demeniz, kod kokusunun ilk işaretidir. Ünite Testleri Yazma, kodu daha test edilebilir hale getirmek için genellikle farklı kodlar yazdığınız anlamına gelir. Bu benim için iyi bir şey olduğunu düşünüyorum çünkü yıllar boyunca test yazmak zorunda olduğum kod yazarken, daha iyi bir tasarıma zorluyordum.
Bilmiyorum. Pek çok yer birim testi yapmaz, ancak kodun kalitesi iyidir. Microsoft, birim sınaması yapıyor, ancak Bill Gates sunumunda mavi bir ekran verdi.
Ünite Testi kesinlikle çabaya değer. Maalesef, uygulanacağı zor (ama ne yazık ki yaygın) bir senaryo seçtiniz.
Birim testlerden elde edeceğiniz en iyi fayda, onu sıfırdan kullanırken kullanmaktır - birkaç, seçkin, küçük projede, sınıflarımı uygulamadan önce ünite sınavlarımı yazabilecek kadar şanslı oldum (arayüz zaten bu noktada tamamlandı). puan). Uygun birim testleriyle, sınıfta hala bebeklik dönemindeyken hataları bulup düzelteceksiniz ve kuşkusuz gelecekte entegre olacakları karmaşık sistemin yakınında hiçbir yerde değil.
Yazılımınız tamamen nesne yönelimli ise, çok fazla çaba göstermeden sınıf düzeyinde birim testi ekleyebilmelisiniz. Eğer bu kadar şanslı değilseniz, yine de nerede olursanız olun ünite testini uygulamaya çalışmalısınız. Yeni işlevler eklediğinizde, yeni parçaların net arabirimlerle iyi tanımlandığından ve birim testlerinin hayatınızı çok daha kolay hale getirdiğini göreceksiniz.
Konuyla ilgili çok büyük bir blog yazısı yazdım. Sadece ünite testlerinin işe yaramayacağını buldum ve son başvuru tarihleri yaklaşınca genellikle kesiliyor.
"Test-sonra" doğrulama bakış açısıyla birim testinden bahsetmek yerine, uygulamadan önce bir spesifik/test/fikir yazmaya karar verdiğinizde bulunan gerçek değere bakmalıyız.
Bu basit fikir, yazılım yazma biçimimi değiştirdi ve eski haline geri dönmeyeceğim.
Henüz kimsenin bahsetmediği şeylerden biri, tüm geliştiricilerin mevcut herhangi bir otomatik testi çalıştırmak ve güncellemek için taahhütte bulunmalarıdır. Yeni gelişme nedeniyle geri dönüp kırıldığınız otomatik testler çok fazla değer kaybediyor ve otomatik testlerin gerçekten acı verici olmasını sağlıyor. Geliştiricinin kodu manuel olarak test etmesi nedeniyle bu testlerin çoğu hataları göstermeyecektir, bu nedenle bunları güncellemek için harcanan zaman sadece boşa harcanır.
Başkalarının birim testlerinde yaptıkları işi yok etmemeye şüpheci olmak, testten değer elde etmek için çok daha önemlidir ve daha kolay olabilir.
Depodan her güncelleyişinizde yeni özellikler nedeniyle kırılan testlerin güncellenmesi saatler geçirmek ne verimli ne de eğlencelidir.
TDD'yi birkaç yıl önce keşfettim ve o zamandan beri bütün evcil hayvan projelerimi kullanarak yazdım. TDD'nin birlikte kovbolacak bir projenin kabaca aynı zamanda sürdüğünü, ancak son üründe başarı hissine yardımcı olamayacağıma dair güvenim arttığını tahmin ettim.
Ayrıca tasarım tarzımı da geliştirdiğini hissediyorum (bir şeylerle alay etmem gerektiğinde arayüz odaklı) ve üst kısımdaki yeşil yazı yazarken, "kodlama kabızlığı" na yardımcı oluyor: ne olduğunu bilmediğinizde Bir sonraki yazmak için veya önünüzde göz korkutucu bir işiniz varsa, küçük yazabilirsiniz.
Son olarak, TDD'nin bugüne kadarki en kullanışlı uygulamasının hata ayıklamada olduğunu, ancak projeyi hatayı tekrarlanabilir bir şekilde üretmeye teşvik edebileceğiniz bir sorgulayıcı çerçeve geliştirmiş olmanızdan dolayı buluyorum.
Evet - Ünite Testi kesinlikle çabaya değer ancak gümüş bir mermi olmadığını bilmelisiniz. Ünite Testi iştir ve testi güncel tutmak ve kod değişiklikleri ile ilgili tutmak için çalışmak zorunda kalacaksınız, ancak sunulan değer, harcadığınız emeğe değecektir. Cezasızlıkla yeniden yönlendirme yeteneği her zaman işlevselliği doğrulayabileceğiniz gibi büyük bir avantajdır herhangi bir değişiklik kodundan sonra testlerinizi çalıştırarak. İşin püf noktası, tam olarak test ettiğiniz iş ünitesine ya da test gereksinimlerini nasıl iskele ettiğinize ve bir ünite testinin gerçekten işlevsel bir test olduğunda, vb. Takılmamaktır. İnsanlar bu konular hakkında saatlerce tartışacaklar. sonunda ve gerçek şu ki, yazma kodunuz olarak yaptığınız herhangi bir test, bunu yapmamaktan daha iyidir. Diğer aksiyom, nitelik değil niceliktir - temelde anlamsız olan 1000'lerin testine sahip kod tabanları gördüm, çünkü geri kalanlar gerçekten faydalı olan hiçbir şeyi veya belirli alanın ticari kuralları, vb. Ayrıca% 30'luk kod kapsamına sahip kod tabanları da gördüm, ancak testler ilgili, anlamlı ve gerçekten harikaydı, çünkü kodun temel işlevlerini test ettiler ve kodun nasıl kullanılması gerektiğini ifade ettiler.
Yeni çerçeveler veya kod tabanlarını araştırırken en sevdiğim püf noktalardan biri, işlerin nasıl yürüdüğünü keşfetmek için 'bunun' birim testlerini yazmak. Kuru bir doktora okumak yerine yeni bir şey hakkında daha fazla bilgi edinmek için harika bir yoldur :)
Son zamanlarda iş yerimde aynı deneyimi yaşadım ve birçoğunun teorik faydaları bildiğini ama özellikle kendilerine faydaları hakkında satılmaları gerektiğini gördüm, bu yüzden burada kullandığım noktalar (başarıyla):
ve büyük olanı ...
Tecrübelerime göre, birim testler ve entegrasyon testleri karmaşık yazılım ortamlarında "ZORUNLU" olmalıdır.
Ekibinizdeki geliştiricileri birim testleri yazmaya ikna etmek için, birim test regresyon analizini geliştirme ortamınıza entegre etmeyi düşünebilirsiniz (örneğin günlük inşa işleminizde).
Geliştiriciler bir ünite testi başarısız olursa, sorunu bulmak için hata ayıklamak için çok fazla zaman harcamak zorunda kalmayacaklarını öğrendikten sonra, onları yazmaya daha fazla teşvik edileceğini biliyorlar.
İşte böyle bir işlevsellik sağlayan bir araç:
NUnit kullanıyorsanız basit ama etkili bir demo NUnit'in kendi test takımlarını önlerinde çalıştırmaktır. Gerçek bir test paketi görmek bir kod temeli bir egzersiz programı bin kelime değerinde ...
Ünite testi hakkında akılda tutulması gereken tek şey, geliştirici için bir rahatlık olmasıdır.
Buna karşılık, fonksiyonel testler kullanıcılar içindir: ne zaman bir fonksiyonel test eklerseniz, kullanıcının göreceği bir şeyi denersiniz. Birim testi eklediğinizde, hayatınızı bir geliştirici olarak kolaylaştırıyorsunuz. Bu bakımdan bir lüks biraz.
Bir ünite yazma veya işlevsel bir test arasında seçim yapmanız gerektiğinde bu ikilemi aklınızda bulundurun.
Buradaki çoğunluğun karşısındaki bakış açısına katılıyorum: Ünite Testleri Yazmak Tamam Değildir Özellikle prototip ağırlıklı programlama (örneğin AI) ünite testiyle birleştirmek zordur.
Birim testi, herhangi bir geliştiricinin kafasında tutabildiğinden daha büyük projelerde çok yardımcı olur. Check-in işleminden önce ünite test takımını çalıştırmanıza izin verir ve bir şey bozup kırmadığınızı keşfederler. Bu, bir başkasının kontrol ettikleri bir hatayı düzeltmesini beklerken ya da değişikliklerini geri alma zorluğuna giderken oturmak ve baş parmaklarınızı titretmek gibi durumlarda bir lotunu azaltır. bazı işleri halledebilirsiniz. Ayrıca yeniden yapılanmada çok değerlidir, bu nedenle yeniden yapılanmış kodun orijinal kodun yaptığı tüm testleri geçtiğinden emin olabilirsiniz.
Birim test paketi ile bir tanesi özelliklerin geri kalanını eksiksiz tutarken koda değişiklikler yapabilir. Bu büyük bir avantaj. Yeni özelliği kodlamayı bitirdiğinizde Unit test sutie ve regression test takımı kullanıyor musunuz?.
Birim testinin bütün amacı testi kolaylaştırmaktır. Otomatikleştirildi. "test yap" ve bitirdin. Karşılaştığınız sorunlardan biri kodu test etmek zorsa, birim sınamasını kullanmanın en iyi nedeni budur.
Daha bugün, daha önce bir birim testinin yazıldığı sınıfı değiştirmek zorunda kaldım.
Testin kendisi iyi yazılmış ve henüz düşünmediğim test senaryolarını içeriyordu.
Neyse ki tüm testler geçti ve yaptığım değişiklik hızlı bir şekilde doğrulandı ve test ortamına güvenle alındı.
Yazılımı manuel olarak test ettiğinizde, normal olarak kullandığınız küçük bir testler/eylemler grubunuz olur. Sonunda, girdi verilerinizi veya işlemlerinizi otomatik olarak değiştirerek, bilinen sorunların arasında kendiniz gezinebilirsiniz. Ünite testleri, işlerin düzgün çalışmadığını size hatırlatmak için orada bulunmalıdır.
Koddan önce test yazmanızı, ana kodun işlevselliğini geliştirmek için yeni testler/veriler eklemenizi öneririm!
Bir fizik öğrencisi olarak, kodumun gerektiği gibi çalıştığını gerçekten ispat kullanmaya yöneliyorum. Bunu mantıklı bir şekilde ispatlayabilirsiniz; bu, uygulama daha karmaşık hale geldikçe büyük ölçüde zorlaşır veya iyi testler yoluyla (mümkün olduğunca yakın) deneysel bir işlev kanıtı yapabilirsiniz.
Mantıksal bir fonksiyon kanıtı sağlamazsanız, test etmeniz gerekir. Tek alternatif "Kodun çalıştığını düşünüyorum ..." demek.
@George Stocker "Maalesef kod tabanımız kolay test yapmanıza izin vermiyor.". Herkes birim testinin faydası olduğunu kabul eder, ancak bu kod bazında maliyetlerin yüksek olduğu anlaşılmaktadır. Maliyetler faydalardan daha büyükse neden bu konuda hevesli olmalılar? İş arkadaşlarınızı dinleyin; belki onlar için birim testlerin algılanan acıları, birim testlerin algılanan değerinden daha büyüktür.
Spesifik olarak, mümkün olan en kısa sürede değer kazanmaya çalışın ve bazı "xUnit yeşil" değerinde bir dokunuş değil, kullanıcı ve bakıcıların değer verdiği temiz kod. Belki bir yineleme için birim testlerine karar vermeli ve daha sonra çabaya değip değmeyeceğini tartışmalısınız.
Test ettiğiniz ilk şeyleri birim testi ile ilgili yapmayın. Ben çoğunlukla Perl'de çalışıyorum, bu yüzden bunlar Perl'e özel örneklerdir, ancak uyarlayabilirsiniz.
Her modül doğru yüklenir ve derlenir mi? Perl'de, bu, kod tabanındaki her bir Foo.pm için bir Foo.t oluşturma meselesidir:
use_ok( 'Foo' );
Tüm POD (Düz Ol 'Dokümantasyonu) uygun şekilde biçimlendirilmiş mi? Tüm dosyalarda tüm POD formatlarının geçerliliğini doğrulamak için Test :: Pod kullanın.
Bunların büyük şeyler olduğunu düşünmeyebilirsiniz ve değillerdir, ancak biraz fazlalık avlayacağınızı garanti ederim. Bu testler saatte bir kez yapıldığında ve birinin erken kararını verdiğinde, insanlara "Hey, bu çok havalı" der.
Birim testinin yararlarından biri tahmin edilebilirliktir.
Ünite testinden önce, bir şeyi kodlamanın ne kadar zaman alacağını büyük ölçüde doğruluk derecesine göre tahmin edebilirdim, ancak hata ayıklamak için ne kadar zamana ihtiyacım olacağını değil.
Bu günlerde hangi testleri yazacağımı planlayabildiğim için kodlamanın ne kadar süreceğini biliyorum ve kodlamanın sonunda sistem zaten hata ayıklandı! Bu, baskı sürecinin çoğunu ortadan kaldıran ancak yine de tüm neşeyi koruyan geliştirme sürecine öngörülebilirlik getiriyor.
Birim Testi, yüksek kalite kodu için en çok kullanılan yöntemlerden biridir. Daha istikrarlı, bağımsız ve belgelenmiş bir koda katkısı kanıtlanmıştır. Birim test kodu, deponuzun ayrılmaz bir parçası olarak kabul edilir ve ele alınır ve bu nedenle geliştirme ve bakım gerektirir. Bununla birlikte, geliştiriciler çoğu kez kaynakların, beklenenden daha verimli olmayan birim testlere yatırım yaptığı bir durumla karşı karşıya kalmaktadır. İdeal bir dünyada, kodladığımız her yöntem kodunu kapsayan ve doğruluğunu onaylayan bir dizi test yapacaktır. Ancak, genellikle zaman kısıtlamaları nedeniyle ya bazı testleri atlıyoruz ya da kalitesiz olanları yazıyoruz. Bu gerçeklikte, birim test geliştirme ve bakımına harcanan kaynakların miktarını göz önünde bulundurarak, en çok hangi kodu test etmeyi hak ettiğine dair uygun zaman göz önüne alındığında, kendisine sorulması gerekir. Ve mevcut testlerden, hangi testler gerçekten korunmaya ve sürdürülmeye değer? Bakınız burada
Birim testi, genel geliştirme maliyetlerini düşürürken daha az hata içeren yazılımı serbest bırakmanıza yardımcı olur. ünite testinin faydaları hakkında daha fazla okumak için bağlantıya tıklayabilirsiniz.
Kimi ikna etmeye çalışıyorsun? Mühendisler veya müdür? Eğer mühendis çalışma arkadaşlarınızı ikna etmeye çalışıyorsanız, bence en iyi tercihiniz yüksek kalitede bir yazılım yapma isteklerine hitap etmek. Hata bulduğunu gösteren çok sayıda çalışma var ve eğer iyi bir iş yapmayı önemsiyorlarsa, bu onlar için yeterli olacaktır.
Eğer yönetimi ikna etmeye çalışıyorsanız, büyük olasılıkla, tespit edilemeyecek kusurların maliyetinin testlerin yazılmasının maliyetinden daha büyük olduğunu söyleyerek bir tür maliyet/fayda gerekçesi yapmanız gerekecektir. Müşteri güveni kaybı, vb. Gibi kaçınılmaz maliyetleri de eklediğinizden emin olun.
Bu çok. Net merkezli, ancak kimse denedi Pex?
Denemeye kadar çok kuşkuluydum - ve vay, ne performans. Düşünceme başlamadan önce "Bu kavram tarafından ikna edilmeyeceğim, aslında ne olduğunu anlayana kadar doing Bana fayda sağla". Fikrimi değiştirmek ve "Yapmıyorum care orada ölümcül istisna riskinin olduğunu nasıl bildiğinizi söylemek benim için tek bir adım attı, ancak orada is ve şimdi bununla başa çıkmam gerektiğini biliyorum "
Belki de bu davranışın tek dezavantajı, everything işaretlemektir ve size altı ay biriktirme hakkı verir. Ancak, eğer kod borcunuz olsaydı, her zaman kod borcunuz vardı, sadece bilmiyordunuz. Bir PM 'ye söylemek gerekirse, bir kaç düzine farkında olmadan önce iki yüz binlik başarısızlık puanı vardır; bu, kavramın ilk önce açıklandığı gibidir).