İş yerinde birim testleri kullanıyor musunuz? Onlardan ne gibi avantajlar elde ediyorsunuz? [kapalı]

Kodumu incelemek ve birim testi uygulamak planlıyordum, ancak meslektaşlarımla konuştuktan sonra, bazıları bana bunun gerekli olmadığını ve çok az yararı olduğunu söyledi. Ayrıca sadece birkaç şirketin üretim yazılımı ile birim test yaptığını iddia ediyorlar.

İnsanların iş yerinde birim testlerini nasıl uyguladıklarını ve bunları kullanmaktan ne gibi yararlar elde ettiklerini merak ediyorum, örneğin, daha iyi kod kalitesi, uzun vadede geliştirme süresinin azalması vb.

bazıları bana bunun gerekli olmadığını söylüyor

Eh, katı anlamda haklılar: test, kod incelemeleri, kaynak kontrolü vb . De kesinlikle gerekli değildir . Sadece çok az mantıklı geliştirici uzun vadede bunlar olmadan çalışır. Çoğumuz bunların neden en iyi uygulamalar olduğunu (genellikle zor yoldan, kendi hatalarımızdan) öğrendik.

ve çok az yararı var.

Bu değil çoğu durumda doğrudur. Yani, önümüzdeki yıllarda kullanımda - yani bakımda - olması gereken üretim yazılımından bahsedersek.

Ayrıca, sadece birkaç şirketin üretim yazılımı ile birim test yaptığını iddia ediyorlar.

Bu doğru olabilir (deneyimimde daha az da olsa), ancak birim testin değeri hakkında söylenecek bir şey yok . Bunun aksine eski şaka "Bok iyidir - 50 milyar sinek yanlış olamaz!" ;-)

İşinize birim testi uyguladınız ve bundan ne elde ettiniz? (örneğin daha iyi kod kalitesi, uzun vadede zamanı azaltın vb.)

İşimde, mümkün olan her an, 10 yılı aşkın süredir birim testleri uyguluyorum. Koduma olan güven duygusu, işe yaradığını bilerek - ve her zaman, her yerde, birkaç saniyede, tekrar tekrar inanmak yerine, tekrar tekrar kanıtlayabilirim - paha biçilemez. Mevcut işlevselliği bozma korkusu olmadan kodumu yeniden düzenleme, tasarımını geliştirme veya hataları düzeltme cesareti veriyor. "Kod yaz ve dua et" in o eski günlerine asla geri dönemezdim.

Birim testler yapıyorum ama işte (ya da çok az değil)

Elde ettiğim testin temel faydaları, yeniden düzenleme işleminin çok daha kolay olması ve regresyonun (yani, önceden düzeltilmiş hataların yeniden sunulması) fark edilmesidir.

Testler 'derleme' ile yaşıyor: yazılımları testlerle kontrol ediyorsunuz ve tüm testler modifikasyonunuzla çalışana kadar check-in yapmıyorsunuz.

Bu yüzden, tecrübelerime göre, yalnız kurt tarzında yapıldığında sınav yazma neredeyse işe yaramaz. Testlerinizi her zaman diğerlerinin yaptığı değişiklikler için düzeltmek zorunda kaldığınızda, testler iş arkadaşlarınız tarafından silinebildiğinde (önceki işlerimde gerçekleşebilir) çünkü 'konuşlandırmama izin vermeyecekler', vb. ekibin geri kalanı tarafından anında yakılan faydalar.

Tüm ekip kabul ettiğinde (ve kolay olan 1 kişilik bir ekipte), deneyimlerime göre, testler Projenin kalitesi, stili ve sağlamlığı için büyük bir faydadır.

Ancak dürüstçe 'sadece birkaç şirket kodlarını otomatik olarak test ettiğine' inanan ve yine de zaman kaybı olduğuna ikna olan bir takımda, faydaları kazanmak için çok az umut var gibi görünüyor, ancak büyük bir olasılık hataları belirtirken 'zaman kaybından' sorumludur.

Testleri uygulamaya koymanın en iyi şansı tamamen sizin sorumluluğunuzda olan küçük bir proje olacaktır. Orada parlama ve testlerin değerini gösterme fırsatına sahip olacaksınız.

Meslektaşlarınızla birlikte olma eğilimindeyim, ancak sadece bir noktaya kadar.

Birim testleri ile ilgili sorun, kodun üstünkörü incelemesinin ne olursa olsun çalışacağını ortaya çıkardığı önemsiz vakalara sıklıkla ve dikkatsizce yazılmasıdır. Örneğin:

def add(x, y)
  x + y
end

Eklemenin gerçekten seçilmiş kullanım vakaları için gerçekten işe yarayacağından emin olmak için bir düzine testle birlikte. Yaa ...

Birim testinin ardındaki genel öneri şudur: Kodunuzda hata yoksa, bunun nedeni yeterince test etmemenizdir. Şimdi, uygun birim testleri ne zaman yazılır. Yanıtlar:

1. Test ederken
2. Hata ayıkladığınız zaman
3. Gerçekten zor şeyler geliştirirken

Her birini inceleyelim, bir çeşit web uygulaması geliştirdiğinizi varsayalım.

Yeni işlevselliğe bazı kodlar yazıyorsunuz ve şu ana kadar makul bir şekilde çalışması gerekiyor. Daha sonra tarayıcınıza ulaşın ve daha yoğun bir şekilde test ederek çalıştığını doğrulayın, değil mi? Bzzzt! ... Yanlış cevap. Birim testi yazıyorsunuz. Şimdi bunu yapmazsan, muhtemelen asla yapmayacaksın. Ve bu, birim testlerinin çok iyi çalıştığı yerlerden biridir: üst düzey işlevselliği test etmek.

Daha sonra bir hata keşfedersiniz (hiç kim kaçırmaz?). Bu bizi ikinci noktaya getiriyor. Kodu geri daldırın ve adımları izlemeye başlayın. Yaptığınız gibi, birim testlerini tutarlı ve doğru verilere sahip olmanın çok önemli olduğu kilit noktalara yazın.

Son nokta ise tam tersi. Çok sayıda meta-programlama içeren kıllı bir işlevsellik tasarlıyorsunuz. Binlerce olası senaryo ile hızlı bir şekilde bir karar ağacı oluşturur ve bunların her birinin çalıştığından emin olmanız gerekir. Bu tür şeyleri yazarken, burada veya orada basit görünümlü bir değişiklik, gıda zincirinin aşağısında hayal edilemez sonuçlara yol açabilir. Diyelim ki, SQL tetikleyicileri kullanarak bir MPTT uygulaması tasarlıyorsunuz - böylece çok satırlı ifadelerle çalışabiliyor.

Bu tür dikenli bir ortamda, genellikle testlerinizi yüksek derecede otomatikleştirmek istersiniz. Bu nedenle, test verilerinin oluşturulmasını otomatikleştirmek için komut dosyaları yazıyorsunuz ve bu test verileri üzerinde tekne yükü birim testleri çalıştırıyorsunuz. Bunu yaparken kaybetmemeniz gereken önemli bir şey de, birim test jeneratörünüz için birim testleri yazmanız gerektiğidir.

Alt satır: birim testleri, kesinlikle evet. Ancak, hata ayıklama için gerçekten ihtiyacınız olana veya bazı kıllı işlevselliklerin düzgün çalıştığından emin olana kadar (ikinci durumda, testlerin kendileri dahil) temel işlevselliklere sahip olun.

Tüm kodlar test edilmelidir. Bununla ilgili başka seçenek yok.

Test edilmemiş kod işe yaramaz: hiçbir şey yapmaya güvenilemez.

Birim testleri yazabilir veya daha üst düzey entegrasyon testleri veya kabul testleri yazmayı umabilirsiniz.

Birim testleri yazmak daha kolay, hata ayıklamak ve yönetmek daha kolaydır.

Entegrasyon testleri, birimlerin gerçekte çalıştığı varsayımlarına dayanmaktadır. Birim testleri olmadan, birimlerin çalıştığını nereden biliyorsunuz? Entegre edilen ünitelerin gerçekten çalıştığını bilmiyorsanız bir entegrasyon testinde nasıl hata ayıklayabilirsiniz?

Kabul testleri de benzer şekilde çalışan tüm parçalara ve parçalara bağlıdır. Parça testi yapmadan parçaların ve parçaların çalıştığını nasıl bilebilirsiniz?

Test zorunludur. Tüm yüksek seviye testleri gerçekte çalışan birimlere bağlıdır.

Böylece birim testi mantıklı bir zorunluluk haline gelir. Başka seçenek yok.

Yazdığım her şey için birim testleri kullanıyorum ve test durumu olmadan test edilmemiş kodların incelenmesine izin vermiyorum. (Ama bir kapsama aracından yoksun, bu yüzden test kapsamı hakkında aklıma gerek var.

Oldukça basit: Kodunuzun çalıştığını gösteremiyorsanız (ve bir test biçimindeki yürütülebilir bir spesifikasyondan daha iyi bir yol mu?) O zaman işe yaramaz .

Bu bana:

• İçiniz rahat olsun: CI sunucum bana tüm kod tabanımın çalıştığını söylüyor.
• Kodumu geliştirme yeteneği: Kodumu yeniden yapılandırabilirim - yeniden düzenleme - yeniden yapılandırmadan sonra hiçbir şey kırmadığımı bilerek.

Birim testi bir disiplindir. Kodun çalışması gerekli olmadığından, genellikle atılır.

Bununla birlikte, sağlam ve daha az hata koduna yol açan kanıtlanmış bir yöntemdir. Daha önce de bahsettiğiniz gibi, size faydaları anlatmam gerektiğini düşünmüyorum. Javascript kütüphaneleri, tam yığın çerçeveler veya tek amaçlı uygulamalar olsun, önde gelen bazı açık kaynak projelerine bakarsanız, hepsi birim testi kullanır.

Kullanmayı önleyen meslektaşlarınızın programcı olmadığından şüpheleniyorum. Eğer öyleyse, diyelim ki Martin Fowler veya Kent Beck gibi değerlerden daha fazla değer verdiğim pek çok insan yok ;).

Çoğu en iyi uygulama gibi, faydalar uzun vadelidir, buna biraz zaman ayırmanız gerekir. Uzun bir yordamsal kod senaryosu yazabilirsiniz, ancak hepimiz 2 yıl sonra yeniden düzenleme yapmanız gerektiğinde bunu nesne yönelimli bir tarzda yazmanızı diliyoruz.

Aynı şey birim testi için de geçerlidir. Uygulamanızda kritik parçalar için birim testleri yazarsanız, kodu yeniden düzenledikten sonra bile her zaman amaçlandığı gibi çalıştığından emin olabilirsiniz. Belki o kadar iyi kodlarsınız ki, hiçbir zaman bir regresyon hatası yaşamazsınız. Ancak yapmazsanız veya ekibinize yeni bir programcı katılırsa, geçmişin hatalarının bir daha olmayacağından emin olmak istersiniz. Sanırım patronunuz da bundan yarım yıl önce çözüldüğünü düşündüğü bir hata raporu vermek zorunda kalmaktan memnun olurdu.

Birim testleri birim test dostu dil, birim test dostu tasarım ve birim test dostu problem gerektirir.

C ++, çok iş parçacıklı tasarım ve GUI bir kabus olacak ve problem kapsamı korkunç olacak.

.NET, yeniden kullanılabilir tek iş parçacıklı dll derleme, saf hesaplama mantığı bir esinti olacak.

Buna değer mi, gerçekten söyleyemem.

Çok fazla refactor musunuz? Kodunuzda "birer birer kapalı" gibi "aptal böcek" görüyor musunuz?

Ne yaparsanız yapın, "birim testleriniz yok, bu yüzden berbat" diye başkalarını eleştiren adam olmayın. Testler size yardımcı olursa, bunun için gidin, eğer değilse, gümüş bir kurşun gibi değiller.

Ben istiyorum , ama ben neredeyse tamamen şirketlerinde çalışan talihsizlik yaşadım sadece umurumda değil kalitesi hakkında ve daha tür sorta belki-if-you-şaşı eserleri bir araya çöp atma odaklanmıştır. Birim testlerinden bahsettim ve bir "Huh?" tür bir görünüm ( SOLID ilkelerini veya ORM'leri veya "tüm statik yöntemlerle sınıfın" ötesindeki tasarım desenlerini veya .NET adlandırma kurallarını izlediğimde aldığım aynı görünüm ). Ben sadece bu şeyleri anlayan bir şirkette bulundum ve maalesef kısa vadeli bir sözleşmeydi ve departman maliyetleri düşürmek için kırpıldı, bu yüzden gerçekten öğrenmek için yeterli zaman yoktu.

Kullanılmayan kukla projelerde birim testlerine başladım, ancak başımı tam gelişmiş TDD / BDD'nin etrafına sokmadım ve bu konuda yardımcı olabilecek bir akıl hocası olmamak, bunu düzgün bir şekilde yapmayı çok zorlaştırıyor.

Onları kullanıyoruz. Elde ettiğimiz büyük bir avantaj, bellek sızıntıları ve ayırma hataları için birim test çerçevesi kontrollerimizdir . Bazen sorun birim test kodunun kendisindedir, ancak genellikle üretim kodundadır.

Bir kod incelemesinde kaçırılan şeyleri bulmak için harika bir yoldur.

Birim testleri de ( çok hızlı ) yapılmalıdır ve her bir işlemden sonra ve ayrıca işlem yapmadan önce geliştiriciler tarafından sürekli entegrasyonunuzun bir parçası olarak çalışabilir . Çalışmamız 20 saniyeden az süren 1.000'den fazla var.

Sistem düzeyinde otomasyon testleri için 40+ dakika ve manuel testler için saat / gün ile karşılaştırın. Tabii ki, birim testleri yapmanız gereken tek test değildir, ancak ince taneli kod düzeyinde, hataları bulmaya ve sistem / entegrasyon testinin dokunamayacağı uç durumları test etmeye yardımcı olabilirler. Kodumuz% 75'in üzerinde karar kapsamı ve% 100 fonksiyon kapsamı ile test edilmelidir, bu da birim testleri olmadan elde edilmesi çok zor olacaktır.

Birim testlerinin değer kattığını söyleyebilirim, ama büyük bir TDD öğrencisi değilim. Kireç motorları veya her türlü motoru gerçekten ve sonra faydalı sınıflar yaptığımda birim testlerden en fazla yararı buluyorum, birim testleri o zaman çok yardımcı oluyor.

Daha fazla veriye bağlı bloklar için otomatik entegrasyon testlerini tercih ediyorum, ancak hepsi veri işindeyim, bu yüzden birçok hata çevremizle ilgili her şeyden daha fazla veri ve bunun için otomatik entegrasyon testleri iyi çalışıyor. Verileri öncesi ve sonrası kontrol etmek ve bu testlerden istisna raporları oluşturmak.

Bu yüzden birim testleri gerçekten değer katıyor, özellikle test ettiğiniz üniteye ihtiyaç duyduğu tüm girişler verilebiliyorsa ve verilen girişle kendi başına çalışabiliyorsa. Yine benim durumumda calc motorları ve yardımcı sınıflar bunların mükemmel örnekleridir.

Maliyetler: Daha yavaş kodlama, Öğrenme Eğrisi, Geliştirici Ataleti

Faydaları: Genel olarak ilk test ettiğimde kendimi daha iyi kod yazarken buldum - SOLID bilge ...

Ancak bence en büyük fayda IMHO, daha sık değişen daha büyük sistemlerde güvenilirlik. İyi bir birim testi, birden fazla sürümü yayınladığınızda poponuzu (benim yaptığımı) kurtaracak ve manuel KG süreçleriyle ilişkili büyük miktarda maliyeti ortadan kaldırabilir. Elbette hatasız kod garanti etmez, ancak tahmin edilmesi zor olanları yakalar. Büyük karmaşık sistemlerde, bu gerçekten çok büyük bir fayda olabilir.

Şansım olduğunda işte bazı birim testler yapıyorum ve meslektaşlarımı da aynı şeyi yapmaya ikna etmeye çalışıyorum.

Bu konuda dindar değilim, ancak deneyimler, birim test edilen yardımcı program ve işletme yöntemlerinin çok sağlam olduğunu ve test aşamasında çok az veya hiç hata göstermediğini gösteriyor ve bu da proje maliyetlerini düşürüyor.

Birim Testlerini kodlamanın ve birim test yürütmesini günlük oluşturma sürecinin bir parçası haline getirmenin gerçek avantajını gördüğümde, 3 farklı kıtada çalışan 30'dan fazla geliştiricinin bulunduğu bir projedeydi. Birim testlerinin gerçekten ışıldadığı yerde, birinin o sınıfı nasıl kullandığını anlamadan, bir sınıfı incelikle değiştireceği zamandı. Kodun test grubuna ulaşmasını beklemek yerine, diğer kişilerin birim testleri değişiklik sonucunda başarısız olmaya başladığında anında geri bildirim vardı. [Bu nedenle, yalnızca kodunuz için yazdıklarınız değil, tüm birim testlerinin rutin olarak yapılması gerekir.]

Birim testi için yönergelerim:

1. Kötü girişler, sınırlar vb. Dahil olmak üzere kodunuz için aklınıza gelebilecek her koşulu test edin.
2. Tüm Modüller için Tüm Birim Testleri düzenli olarak yapılmalıdır (yani gece yapılarının bir parçası olarak)
3. Birim Testi sonuçlarını kontrol edin!
4. Birisi kodunuzda testlerinizi geçen bir hata bulursa, bunun için yeni bir test yazın!

TDD'yi yakın zamanda öğrendim ve bunun çok faydalı olduğunu gördüm. Kodumun beklediğim gibi davrandığına dair daha fazla güven veriyor. Daha kolay yapmak istediğim yeniden faktoring yapmanın yanı sıra. Bir hata bulunduğunda, test boyunca tekrar gösterilmemesini sağlayabilirsiniz.

En zor kısmı iyi birim testleri yazmak.

Kodunuz için iyi bir ölçüttür.