Birim Testi çabaya değer mi? [kapalı]

Birim testini üzerinde çalıştığım ekibin gelişim sürecine entegre etmek için çalışıyorum ve bazı şüpheler var. Şüpheci geliştiricileri birime Ünite Testinin değeri konusunda ikna etmenin iyi yolları nelerdir? Özel durumumda, işlevsellik veya sabit hatalar ekledikçe Birim Testleri ekliyoruz. Ne yazık ki kod tabanımız kolay testlere uygun değildir.

Her gün ofisimizde böyle bir değişim var:

"Adamım, sadece birim testlerini seviyorum, bir şeyin işleyişinde bir sürü değişiklik yapabildim ve sonra testi tekrar üzerinden geçirerek hiçbir şeyi kırmadığımı doğrulayabildim ..."

Ayrıntılar günlük olarak değişir, ancak duygu değişmez. Birim testleri ve test güdümlü geliştirme (TDD) o kadar çok gizli ve kişisel yararın yanı sıra, kendileri yapana kadar birisine gerçekten açıklayamayacağınız bariz faydalara sahiptir.

Ama bunu görmezden gelmek, benim girişimim!

1. Birim Testleri, kodda hızlı bir şekilde büyük değişiklikler yapmanıza olanak tanır. Şimdi çalıştığını biliyorsunuz çünkü testleri yaptınız, yapmanız gereken değişiklikleri yaptığınızda, testleri tekrar çalıştırmanız gerekiyor. Bu saatler kazandırır.

2. TDD, kodlamayı ne zaman durduracağınızı anlamanıza yardımcı olur. Testleriniz, şimdilik yeterince yaptığınız konusunda güven veriyor ve ayarlamayı durdurabilir ve bir sonraki şeye geçebilir.

3. Daha iyi kod elde etmek için testler ve kod birlikte çalışır. Kodunuz kötü / hatalı olabilir. TEST'iniz kötü / buggy olabilir. TDD'de, hem kötü / buggy olmanın düşük olma şansı konusunda bankacılık yapıyorsunuz . Genellikle düzeltilmesi gereken testtir, ancak bu hala iyi bir sonuçtur.

4. TDD, kabızlığın kodlanmasına yardımcı olur. Önümüzdeki büyük ve korkutucu bir iş parçasıyla karşılaştığınızda, testler hızlı bir şekilde hareket etmenizi sağlayacaktır.

5. Birim Testleri üzerinde çalıştığınız kodun tasarımını gerçekten anlamanıza yardımcı olur. Bir şey yapmak için kod yazmak yerine, kodu tabi tuttuğunuz tüm koşulları ve bundan hangi çıktıları beklediğinizi ana hatlarıyla belirlersiniz.

6. Birim Testleri size anında görsel geri bildirim sağlar, hepimiz yaptığımız tüm bu yeşil ışıkların hissini seviyoruz. Çok tatmin edici. Kesintiden sonra kaldığınız yerden devam etmek çok daha kolaydır, çünkü nereye gitmeniz gerektiğini görebilirsiniz - düzeltilmesi gereken bir sonraki kırmızı ışık.

7. Popüler inanç birimi testinin aksine, iki kat daha fazla kod yazmak veya daha yavaş kodlamak anlamına gelmez. Bir kez sen asmak kez test olmadan kodlama daha hızlı ve daha sağlam. Test kodunun kendisi genellikle önemsizdir ve yaptığınız işe büyük bir ek yük getirmez. Bu sadece bunu yaparken inanacağın bir :)

8. Sanırım "Kusurlu testler, sık sık yürütülen mükemmel testlerden hiç yazılmamış mükemmel testlerden çok daha iyi" diyen Fowler'dı. Bunu, kod kapsamımın geri kalanı acımasızca eksik olsa bile, en yararlı olacağını düşündüğüm testleri yazma izni olarak yorumluyorum.

9. İyi birim testleri, bir şeyin ne yapması gerektiğini belgelemeye ve tanımlamaya yardımcı olabilir

10. Birim testleri, kodun yeniden kullanımına yardımcı olur. Kodunuzu ve testlerinizi yeni projenize geçirin. Testler tekrar yapılana kadar kodu değiştirin.

Katıldığım bir çok iş Birim Testi iyi yapmıyor (web uygulaması kullanıcı etkileşimleri vb.), Ancak buna rağmen hepimiz bu mağazada test bulaşmış ve testlerimizi bağladığımız zaman çok mutluyuz. Yaklaşım yeterince tavsiye edemez.

Ünite testi spor salonuna gitmek gibidir. Bunun sizin için iyi olduğunu biliyorsunuz, tüm argümanlar mantıklı. Harika bir ilk acele var, ancak birkaç gün sonra belaya değip değmeyeceğini merak etmeye başlıyorsunuz. Giysilerinizi değiştirmek ve bir hamster tekerleğine koşmak için gününüzden bir saat ayırıyorsunuz ve gerçekten bacak ve kollardan başka bir şey kazandığınızdan emin değilsiniz.

Sonra, belki bir ya da iki hafta sonra, tıpkı ağrı giderken, bir Büyük Son Tarih yaklaşmaya başlar. Her uyanış saatini "işe yarar" işler yapmaya çalışarak geçirmeniz gerekiyor, böylece spor salonuna gitmek gibi yabancı şeyleri kesiyorsunuz. Alışkanlıktan düşüyorsunuz ve Büyük Son Tarih bittiğinde kareye geri dönüyorsunuz. Spor salonuna geri dönmeyi başarabilirseniz, ilk gittiğiniz gibi ağrılı hissedersiniz.

Yanlış bir şey yapıp yapmadığınızı görmek için biraz okuma yaparsınız. Egzersizin erdemlerini öven tüm zinde, mutlu insanlara karşı biraz irrasyonel bir duygu hissetmeye başlarsınız. Çok fazla ortak yönünüzün olmadığını fark ediyorsunuz. Spor salonuna gitmek için yoldan 15 dakika sürmek zorunda değiller; binalarında bir tane var. Egzersizin yararları hakkında kimseyle tartışmak zorunda değiller; sadece herkesin yaptığı ve önemli kabul ettiği bir şeydir. Bir Büyük Son Tarih yaklaştığında, egzersizin patronunuzun yemeyi bırakmanızı isteyebileceğinden daha fazla gereksiz olduğu söylenmez.

Dolayısıyla, sorunuzu cevaplamak için Birim Testi genellikle çabaya değer, ancak gereken çaba miktarı herkes için aynı olmayacaktır. Kod kalitesine gerçekten değer vermeyen bir şirkette spagetti kod tabanı ile uğraşıyorsanız, Birim Testi çok fazla çaba gerektirebilir . (Birçok yönetici Unit Testing'in övgülerini söyleyecektir, ancak bu önemli olduğunda buna sadık kalacakları anlamına gelmez.)

Ünite Testini çalışmalarınıza tanıtmaya çalışıyorsanız ve beklediğiniz tüm güneş ışığı ve gökkuşağıları görmüyorsanız, kendinizi suçlamayın. Birim Testinin sizin için çalışmasını sağlamak için yeni bir iş bulmanız gerekebilir.

İkna etmenin en iyi yolu ... bir hata bulmak, bunun için bir birim testi yazmak, hatayı düzeltmek.

Bu hatanın tekrar ortaya çıkması pek olası değildir ve testinizle kanıtlayabilirsiniz.

Bunu yeterince yaparsanız, diğerleri hızlı bir şekilde yakalanır.

thetalkingwalnut soruyor:

Şüpheci geliştiricileri birime Ünite Testinin değeri konusunda ikna etmenin iyi yolları nelerdir?

Buradaki herkes, birim testinin iyi olmasının nedenini maviden çıkaracak. Bununla birlikte, birisini bir şeyden ikna etmenin en iyi yolunun argümanlarını dinlemek ve bunu nokta nokta ele almak olduğunu görüyorum . Endişelerini sözlü olarak dinlemeye ve onlara yardımcı olursanız, her birine hitap edebilir ve belki de onları bakış açınıza dönüştürebilirsiniz (veya en azından onları ayakta durmadan bırakabilirsiniz). Kim bilir? Belki de birim testlerin durumunuza neden uygun olmadığını ikna edeceklerdir. Muhtemel değil, ama mümkün. Belki de argümanlarını birim testlerine karşı yayınlarsanız, karşı değişkenlerin tanımlanmasına yardımcı olabiliriz.

Argümanın her iki tarafını da dinlemek ve anlamak önemlidir. İnsanların kaygılarına bakmadan birim testlerini gayretle benimsemeye çalışırsanız, dini bir savaş (ve muhtemelen gerçekten değersiz birim testleri) ile sonuçlanacaksınız. Yavaşça benimser ve en düşük maliyetle en fazla yararı göreceğiniz yere uygulayarak başlarsanız, birim testlerin değerini gösterebilir ve insanları ikna etme şansınız daha yüksek olabilir. Bunun göründüğü kadar kolay olmadığını anlıyorum - ikna edici bir argüman oluşturmak için genellikle biraz zaman ve dikkatli metrikler gerektirir.

Birim testleri, diğerleri gibi bir araçtır ve faydaların (böcek yakalama) maliyetlerden (bunları yazma çabası) ağır basacak şekilde uygulanmalıdır. Anlamsız ve nerede olduklarını kullanmayın ve bunların sadece araç cephaneliğinizin bir parçası olduklarını hatırlayın (örn. Denetimler, iddialar, kod analizörleri, biçimsel yöntemler, vb.). Geliştiricilerime söylediklerim şudur:

1. Neden gerekli olmadığına dair iyi bir argümanları varsa (örneğin buna değer olmak için çok basit veya buna değer olmak çok zor) ve yöntemin başka türlü nasıl doğrulanacağını (örneğin, denetim, iddialar) bir yöntem için test yazmayı atlayabilirler. , biçimsel yöntemler, etkileşimli / entegrasyon testleri). Teftişler ve resmi kanıtlar gibi bazı doğrulamaların bir noktada yapıldığını ve üretim kodu her değiştiğinde tekrarlanması gerektiğini düşünürken, birim testleri ve iddiaları regresyon testi olarak kullanılabilir (bir kez yazılır ve daha sonra tekrar tekrar yürütülür) ). Bazen onlara katılıyorum, ancak daha sıklıkla bir yöntemin gerçekten çok basit mi yoksa birim testi yapmak için çok mı zor olduğu hakkında tartışacağım.

   • Bir geliştirici, bir yöntemin başarısız olmayacak kadar basit olduğunu iddia ederse, bunun için 5 satırlık basit bir birim testi yazmak için gerekli 60 saniyeyi almaya değmez mi? Bu 5 kod satırı her gece (her gece inşa edersiniz, değil mi?) Gelecek yıl veya daha fazla süreyle çalışacak ve tanımlanması 15 dakika veya daha uzun sürmüş bir sorunu yakalamak için bir kez bile olsa çabaya değer olacaktır. ve hata ayıklama. Ayrıca, kolay birim testlerinin yazılması, geliştiricinin iyi görünmesini sağlayan birim testlerinin sayısını artırır.

   • Öte yandan, bir geliştirici bir yöntemin test edilmesi için çok zor göründüğünü (gerekli olan önemli çabaya değmez) savunuyorsa, belki de bu, kolay parçaları test etmek için yöntemin bölünmesi veya yeniden düzenlenmesi gerektiğinin iyi bir göstergesidir. Genellikle bunlar, tek tonlar, geçerli saat veya veritabanı sonuç kümesi gibi dış kaynaklara dayanan alışılmadık kaynaklara dayanan yöntemlerdir. Bu yöntemlerin genellikle kaynağı alan bir yönteme (örneğin, getTime () işlevini çağırır) ve kaynağı bağımsız değişken olarak alan bir yönteme (örneğin, zaman damgasını parametre olarak alır) dönüştürülmesi gerekir. Ben kaynak alır yöntemi test atlamak izin ve bunun yerine şimdi bir bağımsız değişken olarak kaynak alır yöntemi için bir birim sınama yazın. Bu, genellikle birim testinin yazılmasını çok daha basit ve bu nedenle yazmaya değer hale getirir.

2. Geliştiricinin, birim testlerinin ne kadar kapsamlı olması gerektiğine dair bir "kum çizgisi" çizmesi gerekir. Daha sonra geliştirmede, bir hata bulduğumuzda, daha kapsamlı birim testlerinin sorunu yakalayıp yakalamayacağını belirlemelidirler. Eğer öyleyse ve bu tür hatalar tekrar tekrar ortaya çıkarsa, "satırı" ileride daha kapsamlı birim testleri yazmaya doğru hareket ettirmeleri gerekir (geçerli hata için birim testinin eklenmesi veya genişletilmesi ile başlayarak). Doğru dengeyi bulmaları gerekiyor.

Birim testleri gerçekleştirmek için onun önemli bir gümüş kurşun değildir ve orada olduğunu çok fazla birim test diye bir şey. İşyerimde öğrendiğimiz dersleri her yaptığımızda kaçınılmaz olarak "daha fazla birim test yazmamız gerekiyor" sözlerini duyuyorum. Yönetim başını salladı çünkü "birim testleri" == "iyi" başlarını çarptım.

Bununla birlikte, "daha fazla birim testi" nin etkisini anlamamız gerekir. Bir geliştirici yalnızca haftada ~ N kod satırı yazabilir ve bu kodun yüzde kaçının üretim kodu ile birim kod arasında olması gerektiğini bulmanız gerekir. Bir gevşek işyeri, birim testleri olarak kodun% 10'una ve üretim kodu olarak kodun% 90'ına sahip olabilir, bu da çok (çok hatalı olsa da) özelliklere sahip ürünle sonuçlanır (MS Word'ü düşünün). Öte yandan,% 90 birim testleri ve% 10 üretim koduna sahip katı bir dükkanda çok az özelliğe sahip kaya gibi sağlam bir ürün olacaktır ("vi" deyin). İkinci ürünün çöküşüyle ​​ilgili raporları asla duyamayabilirsiniz, ancak bunun, kodun kalitesiyle olduğu kadar çok iyi satış yapmamasıyla da ilgili olması muhtemeldir.

Daha da kötüsü, belki de yazılım geliştirmedeki tek kesinlik "değişim kaçınılmazdır" dır. Sıkı mağazanın (% 90 birim testleri /% 10 üretim kodu) tam olarak 2 özelliğe sahip bir ürün oluşturduğunu varsayın (üretim kodunun% 5'i = = 1 özellik olduğu varsayılarak). Müşteri gelir ve özelliklerden 1'ini değiştirirse, bu değişiklik kodun% 50'sini (birim testlerin% 45'i ve üretim kodunun% 5'i) çöker. Lax shop (% 10 birim testleri /% 90 üretim kodu) 18 özelliğe sahip bir ürüne sahiptir ve hiçbiri çok iyi çalışmaz. Müşterileri 4 özelliğinin gereksinimlerini tamamen yeniler. Değişiklik 4 kat daha büyük olmasına rağmen, kod tabanının sadece yarısı çöpe atılır (~% 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ında da düşündüğünüzü belirtmeniz gerekiyor. Eğer akranlarınızı ve / veya yönetiminizi ikna edebilirseniz, güvenilirlik kazanırsınız ve belki de onları kazanma şansınız daha yüksektir.

Birkaç kez ünite testi yaptım ve hala durumuma verilen çabaya değdiğine ikna oldum.

Mantığın çoğunun veritabanında veri oluşturmayı, almayı veya güncellemeyi içerdiği web siteleri geliştiriyorum. Birim test amacıyla veritabanını "alay" denediğimde, çok dağınık ve biraz anlamsız görünüyordu.

İş mantığı etrafında birim testleri yazdığımda, uzun vadede bana hiç yardımcı olmadı. Büyük ölçüde yalnız projeler üzerinde çalıştığım için hangi kod alanlarının üzerinde çalıştığım bir şeyden etkilenebileceğini sezgisel olarak biliyorum ve bu alanları manuel olarak test ediyorum. Müvekkilime olabildiğince çabuk bir çözüm sunmak istiyorum ve birim testi genellikle zaman kaybı gibi görünüyor. Manuel testleri listeler ve kendim yürürüm, giderken işaretlerim.

Geliştiricilerden oluşan bir ekip bir proje üzerinde çalışırken ve birbirlerinin kodlarını güncellerken faydalı olabileceğini görebiliyorum, ancak o zaman bile geliştiriciler yüksek kalitede, iyi iletişim ve iyi yazılmış bir kodda ise genellikle yeterli olmalı diye düşünüyorum. .

Birim testleri ile ilgili harika bir şey, kodunuzun nasıl davranması gerektiğine dair belgeler olarak hizmet etmeleridir. İyi testler bir tür referans uygulaması gibidir ve takım arkadaşları kodlarını kendinizle nasıl entegre edeceğinizi görmek için onlara bakabilirler.

Birim testi, ilk yatırıma değer. Birkaç yıl önce birim testi kullanmaya başladığımdan beri, bazı gerçek faydalar buldum:

• regresyon testi , kodda değişiklik yapma korkusunu ortadan kaldırır (her değişiklik yapıldığında kod işini görmenin veya patlamanın sıcak bir ışıltısı gibi bir şey yoktur)
• diğer ekip üyeleri için yürütülebilir kod örnekleri (ve altı ay içinde kendiniz ..)
• acımasız yeniden düzenleme - bu inanılmaz ödüllendirici, deneyin!

Kod parçacıkları, test oluşturma yükünü azaltmada çok yardımcı olabilir. Saniyeler içinde bir sınıf anahattı ve ilişkili bir birim test fikstürünün oluşturulmasını sağlayan parçacıklar oluşturmak zor değildir.

Mümkün olduğunca az test etmelisiniz!

Yani, amacı ortaya çıkarmak için yeterli birim testleri yazmalısınız. Bu genellikle parıldar. Birim testi size maliyeti. Değişiklik yaparsanız ve testleri değiştirmeniz gerekirse daha az çevik olursunuz. Birim testlerini kısa ve tatlı tutun. Sonra çok değer var.

Çok sık, asla kırılmayacak, büyük ve sakar olan ve çok fazla değer sunmayan birçok test görüyorum, sonunda sizi yavaşlatıyorlar.

Bunu diğer cevapların hiçbirinde görmedim, ama fark ettiğim bir şey çok daha hızlı hata ayıklayabildiğim . Sabitlemenizdeki koda ulaşmak için yalnızca doğru adımlar dizisiyle uygulamanızı ayrıntılı bir şekilde incelemeniz gerekmez, yalnızca bir boolean hatası yaptığınızı ve tekrar yapmanız gerektiğini bulmak için. Birim testi ile, hata ayıkladığınız koda doğrudan girebilirsiniz.

[Yukarıda göremediğim bir nokta var]

"Herkes birim testleri, mutlaka farkına varmazlar - GERÇEK"

Bir düşünün, belki bir dizeyi 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 () ile uygulayarak komut satırından birkaç örnek çalıştırırsınız veya bir düğme ile görsel bir ön uç birleştirirsiniz, işlevinizi birkaç metin kutusuna ve bir düğmeye bağlar ve görürsünüz. ne oluyor.

Bu birim testtir - temel ve kötü bir şekilde bir araya getirilir, ancak birkaç parça için kod parçasını test edersiniz.

Daha karmaşık bir şey yazıyorsunuz. Birkaç üniteyi (birim testi) kullanarak attığınızda hatalar atar ve koda hata ayıklar ve izler bırakırsınız. Siz ilerlerken değerlere bakarsınız ve doğru mu yanlış mı olduğuna karar verirsiniz. Bu bir dereceye kadar birim testtir.

Burada birim testi, bu davranışı gerçekten yapılandırıyor, yapılandırılmış bir kalıpta resmileştiriyor ve kaydediyor, böylece bu testleri kolayca tekrar çalıştırabilirsiniz. Manuel olarak test etmek yerine "uygun" bir birim test senaryosu yazarsanız, aynı miktarda zaman alır veya belki de deneyimlediğiniz kadar az sürer ve tekrar tekrar tekrar kullanabilirsiniz.

Yıllarca, insanları kodları için birim testi yazmaları gerektiğine ikna etmeye çalıştım. Testleri önce yazdılar (TDD'de olduğu gibi) veya işlevselliği kodladıktan sonra olsun, her zaman kod için birim testlere sahip olmanın tüm faydalarını açıklamaya çalıştım. Kimse benimle aynı fikirde değildi. Açık bir şeye katılmıyorsunuz ve herhangi bir akıllı kişi birim test ve TDD'nin faydalarını görecek.

Birim testi ile ilgili sorun, davranışsal bir değişiklik gerektirmesidir ve insanların davranışlarını değiştirmek çok zordur. Kelimelerle, birçok insanın seninle aynı fikirde olmasını sağlayacaksın, ama bir şeyler yapma şekillerinde pek çok değişiklik görmeyeceksin.

İnsanları yaparak ikna etmelisiniz. Kişisel başarınız, sahip olabileceğiniz tüm argümanlardan daha fazla insanı cezbedecektir. Eğer sadece birim test veya TDD'den bahsetmediğinizi, ancak vaaz ettiğiniz şeyi yaptığınızı görürseniz ve başarılı olursanız, insanlar sizi taklit etmeye çalışırlar.

Ayrıca bir lider rolü üstlenmelisiniz, çünkü kimse ilk kez ünite testini yazmaz, bu yüzden nasıl yapılacağı, onlara yol gösterdiği ve mevcut araçlar hakkında onlara koçluk yapmanız gerekebilir. İlk testlerini yazarken onlara yardım edin, kendi yazdıkları testleri gözden geçirin ve onlara kendi deneyimlerinizle öğrendiğiniz hileleri, deyimleri 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 etmek için davranışlarını değiştirecekler.

Değişiklikler gece boyunca gerçekleşmez, ancak biraz sabır ile hedefinize ulaşabilirsiniz.

Test odaklı geliştirmenin sıklıkla göz ardı edilen önemli bir kısmı test edilebilir kodun yazılmasıdır. İlk başta bir tür uzlaşma gibi görünüyor, ancak test edilebilir kodun da sonunda modüler, bakım yapılabilir ve okunabilir olduğunu keşfedeceksiniz. İnsanları ikna etmek için hala yardıma ihtiyacınız varsa , bu birim testin avantajları hakkında güzel ve basit bir sunumdur.

Mevcut kod tabanınız birim sınamaya uygun değilse ve zaten üretime giriyorsa, tüm kodlarınızı yeniden gruplandırmayı deneyerek, birim sınanabilir olması için çözdüğünüzden daha fazla sorun yaratabilirsiniz.

Bunun yerine entegrasyon testinizi geliştirmek için çaba göstermeniz daha iyi olabilir. Birim testi olmadan yazılması daha kolay olan çok sayıda kod var ve eğer bir KG bir gereksinimi belgeye göre işlevselliği doğrulayabilirse, işiniz bitti demektir. Onu yükle.

Aklımda bu klasik örnek bir GridView bağlı bir ASPX sayfasına gömülü bir SqlDataReader olduğunu. Kodun tamamı ASPX dosyasındadır. SQL, saklı bir yordamda. Birim testi nedir? Sayfa yapması gerekeni yaparsa, otomatikleştirecek bir şeyiniz olması için sayfayı gerçekten birkaç katman halinde yeniden tasarlamanız gerekir mi?

Birim testi ile ilgili en iyi şeylerden biri, kodunuzun sizin yaptığınız gibi test edilmesinin daha kolay hale gelmesidir. Testler olmadan oluşturulan önceden var olan kod her zaman zordur, çünkü birim test edilmeleri amaçlanmadığından, sınıflar arasında, e-posta gibi, yapılandırılması zor nesneler arasında yüksek düzeyde bağlantıya sahip olmak nadir değildir. servis referansı gönderme - vb. Ama bunun seni hayal kırıklığına uğratmasına izin verme! Birim testleri yazmaya başladığınızda genel kod tasarımınızın daha iyi hale geleceğini göreceksiniz ve ne kadar çok test ederseniz, başvurunuzu kırmaktan veya hataları tanıtmaktan korkmadan daha fazla değişiklik yapmaya daha fazla güveneceksiniz. .

Kodunuzu birim olarak test etmenin birkaç nedeni vardır, ancak zaman ilerledikçe, testte tasarruf ettiğiniz sürenin bunu yapmak için en iyi nedenlerden biri olduğunu öğreneceksiniz. 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 testlerim bittiğinde, 10 dakikadan daha az bir sürede 400'den fazla test vakası yürütüyorum ve kodda küçük bir değişiklik yapmak zorunda kaldığımda, kodun hala hatalar olmadan çalıştığından emin olmak için tüm bunları aldım dakika. Bu 400+ test vakasını elle çalıştırmak için harcayacağınız zamanı hayal edebiliyor musunuz?

Testler yalnızca bir kez yapmayı planlıyorsanız, otomatik test söz konusu olduğunda - birim testi veya kabul testi olsun - herkes manuel olarak yapabileceğiniz şeyleri kodlamanın boşa harcandığını düşünüyor ve bazen doğrudur. Otomatik testin en iyi yanı, bunları çaba harcamadan birkaç kez çalıştırabilmenizdir ve ikinci veya üçüncü çalıştırmadan sonra, harcadığınız zaman ve çaba zaten ödenir.

Son bir tavsiye, sadece kodunuzu birim olarak test etmek değil, aynı zamanda önce test yapmaya başlamak olacaktır ( daha fazla bilgi için TDD ve BDD'ye bakın)

Birim testleri, bir parçayı yeniden kodlama veya yeniden yazma söz konusu olduğunda da özellikle yararlıdır. İyi bir birim test kapsamına sahipseniz, güvenle refactor yapabilirsiniz. Birim testleri olmadan, hiçbir şeyi kırmamanızı sağlamak genellikle zordur.

Kısacası - evet. Her çabaya değer ... bir noktaya. Testler, günün sonunda, hala kod niteliğindedir ve tipik kod büyümesine çok benzer şekilde, sürdürülebilir ve sürdürülebilir olması için testlerinizin sonunda yeniden düzenlenmesi gerekecektir. Bir ton GOTCHAS var! birim test söz konusu olduğunda, ama adam oh adam oh adam, hiçbir şey, ve demek istediğim hiçbir şey bir geliştiriciye zengin bir birim test setinden daha güvenli değişiklikler yapma imkanı verir.

Şu anda bir proje üzerinde çalışıyorum .... biraz TDD, ve iş kurallarımızın çoğunun test olarak kapsadığı var ... ş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ğıyla nasıl arayüz oluşturduğunu yenilemek zorunda kaldım. Bana birkaç gün sürdü, tüm zaman boyunca kırdığımı ve düzelttiğimi görmek için birim testleri yapmaya devam ettim. Bir değişiklik yap; Testlerinizi oluşturun ve çalıştırın; kırdığın şeyi düzelt. Yıkama, Durulama, Gerektiği kadar tekrarlayın. Geleneksel olarak günlerce QA ve tekne yükü stresi alacak olan şey, bunun yerine kısa ve keyifli bir deneyim oldu.

Önden hazırlayın, biraz ekstra çaba sarf edin ve çekirdek özellikler / işlevsellik ile uğraşmaya başladığınızda 10 kat daha fazla ödeme yapar.

Bu kitabı satın aldım - bu bir xUnit Test bilgisi İncil'i - muhtemelen rafımda en çok başvurulan kitaplardan biri ve günlük olarak danışıyorum: bağlantı metni

Bazen kendim ya da iş arkadaşlarımdan biri, biraz belirsiz hatanın dibine ulaşmak için birkaç saat harcayacak ve hatanın nedeni kodun test edilmediği sürenin% 90'ı bulunduğunda. Birim testi mevcut değildir, çünkü geliştirici zamandan kazanmak için köşeleri keser, ancak daha sonra bu ve daha fazla hata ayıklama kaybeder.

Birim testi yazmak için az zaman harcamak, gelecekteki hata ayıklama saatlerinden tasarruf etmenizi sağlayabilir.

Kötü belgelenmiş, korkunç ve büyük bir kod tabanının bakım mühendisi olarak çalışıyorum. Keşke kodu yazan insanlar bunun için birim testleri yazmışlardı.
Her değişiklik yaptığımda ve üretim kodunu güncellediğimde, bazı koşulları dikkate almadığım için bir hata getirebileceğimden korkuyorum.
Eğer test yazmışlarsa kod tabanında değişiklik yapmak daha kolay ve daha hızlı olacaktır (aynı zamanda kod tabanı daha iyi durumda olacaktır).

Ünite testleri, yıllarca sürmesi gereken ve orijinal kodlayıcılar dışındaki kişiler tarafından kullanılması / değiştirilmesi / geliştirilmesi gereken API veya çerçeveler yazarken çok yararlı olduğunu düşünüyorum.

Birim Testi kesinlikle çabaya değer. Maalesef, bunu uygulamak için zor (ama ne yazık ki yaygın) bir senaryo seçtiniz.

Alacağınız birim testlerinden en iyi yararı, sıfırdan kullanmanızdır - birkaç, seçili, küçük projelerde, sınıflarımı uygulamadan önce birim testlerimi yazmak için yeterince şanslıydım (arayüz zaten bu noktada tamamlanmıştı) nokta). Uygun birim testleri ile, sınıflarınızdaki hataları henüz bebeklik döneminde iken ve şüphesiz gelecekte entegre olacakları karmaşık sistemin yakınında herhangi bir yerde bulamaz ve düzeltirsiniz.

Yazılımınız tamamen nesne yönelimliyse, çok fazla çaba harcamadan sınıf düzeyinde birim testi ekleyebilirsiniz. Eğer o kadar şanslı değilseniz, mümkün olan her yerde birim testlerini dahil etmeye çalışmalısınız. Yeni işlevler eklediğinizde, yeni parçaların net arabirimlerle iyi tanımlandığından ve birim testinin hayatınızı daha kolay hale getirdiğini göreceksiniz.

"Kod tabanımız kolay test edilmesini sağlamaz" dediğinde, bir kod kokusunun ilk işaretidir. Birim Testleri Yazma, kodu daha test edilebilir hale getirmek için genellikle farklı kod yazmanız anlamına gelir. Bu, bence iyi bir şey çünkü yıllar boyunca test yazmak için kod yazarken gördüklerim, daha iyi bir tasarım ortaya koymamı zorladı.

Bilmiyorum. Birçok yerde birim testi yapılmaz, ancak kodun kalitesi iyidir. Microsoft birim testi yapıyor, ancak Bill Gates sunumunda mavi bir ekran verdi.

Konu hakkında çok büyük bir blog yazısı yazdım. Birim testinin tek başına işe yaramayacağını ve son teslim tarihleri ​​yaklaştığında genellikle kesildiğini buldum.

"Test sonrası" doğrulama bakış açısından birim testi hakkında konuşmak yerine, uygulamadan önce bir spesifikasyon / test / fikir yazmaya başladığınızda bulunan gerçek değere bakmalıyız.

Bu basit fikir, yazılım yazma şeklimi değiştirdi ve "eski" yola geri dönmeyeceğim.

Testin ilk gelişimi hayatımı nasıl değiştirdi

Evet - Birim Testi kesinlikle çabaya değer, ancak bunun gümüş bir kurşun olmadığını bilmelisiniz. Birim Testi bir iştir ve testi kod değişiklikleri olarak güncel ve alakalı tutmak için çalışmanız gerekecektir, ancak sunulan değer koymak zorunda olduğunuz çabaya değer. İşlevselliği her zaman doğrulayabileceğiniz için cezasızlıkla yeniden düzenleme yeteneği 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ş birimine veya iskele testi gereksinimlerini nasıl kullandığınıza ve bir birim test gerçekten işlevsel bir test olduğunda, vb. Sonunda ve gerçek şu ki, yazma kodunuz olarak yaptığınız herhangi bir test, bunu yapmamaktan daha iyidir. Diğer aksiyom nicelik değil kalite ile ilgilidir - 1000 'ile kod tabanları gördüm gerisi olarak anlamsız olan test s gerçekten yararlı bir şey veya belirli bir alanın iş kuralları, vb gibi belirli bir etki alanı gerçekten test yok. Ben de% 30 kod kapsamı ile kod tabanları gördüm ama testler için yazılmış kodun temel işlevselliğini test ve kodun nasıl kullanılması gerektiğini ifade ilgili, anlamlı ve gerçekten harika.

Yeni çerçeveleri veya kod tabanlarını keşfederken en sevdiğim hilelerden biri, işlerin nasıl çalıştığını keşfetmek için 'bu' için birim testleri yazmak. Kuru bir dokümanı okumak yerine yeni bir şey hakkında daha fazla bilgi edinmek için harika bir yol :)

Son zamanlarda işyerimdeki aynı deneyimi yaşadım ve çoğunun teorik faydaları bildiklerini gördüm, ancak onlara faydalarından özel olarak satılmak zorunda kaldım, bu yüzden kullandığım noktalar (başarıyla):

• Tüm bunları tek bir işlemde yapabileceğiniz gibi, beklenmedik girdileri (boş göstericiler, sınır dışı değerler, vb.) İşlediğiniz negatif test gerçekleştirirken zaman kazanırlar.
• Değişikliklerin standardı hakkında derleme zamanında anında geri bildirim sağlarlar.
• Normal çalışma sırasında ortaya çıkmayabilecek dahili veri temsillerini test etmek için yararlıdırlar.

ve büyük olan ...

• Birim testine ihtiyacınız olmayabilir, ancak başka biri içeri girdiğinde ve kodu tam olarak anlamadan değiştirdiğinde, yapabileceği aptalca hataları yakalayabilir.

TDD'yi birkaç yıl önce keşfettim ve o zamandan beri tüm evcil hayvan projelerimi yazdım. Bir projeyi birlikte kovboylamak için TDD ile yaklaşık olarak aynı zaman aldığını tahmin ettim, ancak son ürüne olan güvenimde bir başarı hissine yardımcı olamayacağım.

Ayrıca tasarım stilimi geliştirdiğini hissediyorum (birlikte taklit etmem durumunda çok daha arayüz odaklı) ve üstteki yeşil yazı yazdığı gibi, "kodlama kabızlığı" ile yardımcı olur: ne olduğunu bilmediğinizde Bir sonraki yazmak için, ya da önünüzde yıldırıcı bir göreviniz varsa, küçük yazabilirsiniz.

Son olarak, TDD'nin en yararlı uygulamasının hata ayıklamada olduğunu görüyorum, çünkü sadece projeyi hatayı tekrarlanabilir bir şekilde üretmeye hazırlayabileceğiniz sorgulayıcı bir çerçeve geliştirdiyseniz.

Kimsenin henüz bahsetmediği bir şey, tüm geliştiricilerin mevcut herhangi bir otomatik testi çalıştırma ve güncelleme taahhüdünü almaktır. Yeni geliştirme nedeniyle geri döndüğünüz ve kırdığınız otomatik testler çok fazla değer kaybeder ve otomatik testi gerçekten acı verici hale getirir. Bu testlerin çoğu, geliştirici kodu manuel olarak test ettiğinden hataları göstermeyecektir, bu nedenle bunları güncellemek için harcanan zaman sadece israftır.

Şüphecileri, diğerlerinin birim testlerde yaptıkları işi yok etmemeye ikna etmek, testten değer elde etmek için çok daha önemlidir ve daha kolay olabilir.

Depodan her güncelleme yaptığınızda yeni özellikler nedeniyle kırılan testleri güncellemek saat harcamak ne verimli ne de eğlenceli.

NUnit kullanıyorsanız, basit ama etkili bir demo, NUnit'in kendi test paketlerini önlerinde çalıştırmaktır. Bir kod temeli bir egzersiz veren gerçek bir test paketini görmek bin kelimeye bedeldir ...

Birim testi, geliştiricilerin başlarında tutabileceğinden daha büyük projelerde çok yardımcı olur. Check-in yapmadan önce birim test paketini çalıştırmanıza ve bir şey kırıp kırmadığınızı keşfetmenize izin verir. Bu , başka birinin kontrol ettikleri bir hatayı düzeltmesini beklerken ya da değişikliklerini geri alma zahmetine girerek bazı işleri halledebilmeniz için otururken başparmaklarınızı çevirmek zorunda kaldığınız durumlarda çok şey keser . Yeniden düzenleme işleminde de son derece değerlidir, bu nedenle yeniden düzenlenmiş kodun orijinal kodun yaptığı tüm testleri geçtiğinden emin olabilirsiniz.

Birim test paketi ile, özelliklerin geri kalanını olduğu gibi bırakarak kodda değişiklik yapabilirsiniz. Bu büyük bir avantaj. Yeni özelliği kodlamayı bitirdiğinizde Birim test sütunu ve regresyon test paketini kullanıyor musunuz?

Buradaki çoğunluğun karşısındaki bakış açısına katılıyorum: Birim Testleri Yazmamak TAMAM Özellikle prototip ağır programlamanın (örneğin AI) birim testi ile birleştirilmesi zordur.