Birim testi bu kadar iyiyse, neden daha fazla şirket bunu yapmıyor? [kapalı]

Çalıştığım ilk gerçek yazılım şirketi tamamen birim testi (NUnit) ile ilgiliydi. O zamanlar bunun için gerçekten titiz olduğumuzu bilmiyorum - kod kapsamımızın nasıl olduğu hakkında hiçbir fikrim yok ve birim testlerinin çoğunu yazıyordum. O zamandan beri çok sayıda test yapan bazı şirketlerle karşılaştım, ancak bu sandalye testi: bir kişinin orada olmasına dayanır, düşük tekrarlanabilirliğe ve düşük hataları yakalama şansı. Diğer tavır şudur: "gelecekte" devam etmek istedikleri bir şeydi; temelde para gökten düştüğünde.

Birim testini özlüyorum - bu hayatı kolaylaştırıyor. Ancak yeni bir iş aradığımda, birim testinin ya şirketlerin gelecekte "devam etmek" isteyeceği bir şey olduğunu veya hiç yapmadıkları bir şey olduğunu görüyorum (uhh, bir süredir ortalıkta şimdi!). Son 2 yılda baktığım iş taleplerinin% 60-75'inin birim testlerini hiç listelemediğini söyleyebilirim. Bir gereklilik olarak birim test deneyimi olan bir veya iki tane düşünebiliyorum (orta seviye bir geliştirici pozisyonu için).

Yani soru şu, eksik olan nedir? İnsanları daha üretken kıldığını düşünüyorum, ancak bu yalnızca bunu gerçekten yapmak için sağlam bir zaman harcadıktan sonra. Birim testinin maliyet tasarrufu konusunda iyi çalışmalar yok mu? Baktığım şirket tipi mi?

Düzenleme: Başlık biraz şeytani savunucu olsa da, kendimi bir birim testi savunucusu olarak görüyorum.

Deneyimlerime göre, bununla ilgili birkaç faktör var:

1. Yönetim, birim testinin gerçekte ne olduğunu veya neden kendileri için gerçek içsel değeri olduğunu gerçekten anlamıyor.
2. Yönetim, hızlı ürün teslimi ile daha fazla ilgilenme eğilimindedir ve (yanlış bir şekilde) birim testi bu hedefe ters etki olarak görür.
3. Testin yalnızca kalite güvencesine ait olduğuna dair bir yanlış algı var. Geliştiriciler kodlayıcıdır ve test yazamazlar.
4. Araçların ücretsiz olarak temin edilebilmesine rağmen, yönetimin birim testini doğru yapmak için para harcaması gerektiğine dair yaygın bir yanlış algılama var. (Elbette geliştiricinin dikkate alması gereken zaman var, ancak bu gerçekten engelleyici değil.)
5. Will'in cevabı bu cevabı tamamlayacak: Test kodunun değerini belirlemek çok zor (jcollum'u düzenle)

Doğal olarak başka faktörler de var, ancak bunlar şimdiye kadar karşılaştığım şeyler.

1) Zor
2) Zaman alıyor
3) Test kodunun değerini belirlemek çok zor

3. nokta yapışkan bir noktadır. İyi birim testleri hataları azaltır. Ancak iyi üretim kodu da öyle. Birim testleriniz nedeniyle kaç tane hatanın olmadığını nasıl belirlersiniz? Neyin olmadığını ölçemezsin. Çalışmalara işaret edebilirsiniz, ancak bunlar işletme müdürünüzün elektronik tablosuna pek uymuyor.

Tüm suçu "yönetime" yüklemek kolaydır. Ama yönetimi gerçekten özel olarak söylüyorum değil herhangi birim test yapmak?

Genel olarak yönetim, modülerleştirme, soyut veri türleri, tasarım modelleri veya birim testi olsun, size işinizi nasıl yapacağınızı söylemez (ve muhtemelen söylememelidir). Bunlar, başarılı, yetkin bir yazılım mühendisinin uyguladığı, ancak zayıf bir mühendisin uygulamadığı ticaret araçlarıdır.

Bence sorunuzun gerçek cevabı şudur: ünite testi gerçekten zordur ve bilgisayar bilimi öğrencileri bunun için eğitilmemiştir.

Kendi dizgi sınıfınızı yazarken çok kolaydır. Gerçek hayattaki bir ürünü test ederken, powerpoint slaytlarında kimsenin size bahsetmediği zorluklarla karşılaşırsınız:

• Kullanıcı etkileşimi. Uygulamanızın yarısı, kullanıcı arayüzü mantığıdır. Otomatik bir şekilde nasıl test edersiniz, bir düğmeyi hareket ettirdiğinizde bozulmaz?
• Harici API'ler ve çerçevelerle etkileşim. Bir Windows çekirdek sürücüsü yazıyorsanız, bunu nasıl birim testi yaparsınız? Kullandığınız her IRP ve çekirdek işlevi için, etkili bir şekilde işletim sistemi çekirdeği simülasyonu oluşturarak saplamalar yazıyor musunuz?
• Ağ iletişimi 21. yüzyılın şeyidir. Birkaç dağıtılmış bileşenden oluşan bir birim testini nasıl koordine edersiniz?
• İyi test durumlarını nasıl seçersiniz? İnsanların "1000 yinelemeli bir döngüde rastgele şeyler yap ve kırılıp kırılmadığına bak" yaklaşımını denediğini görüyorum. Bunu yaptığınızda, çaba geri dönüşlerden daha fazladır, önemli hatalar gözden kaçar ve birim testi terk edilir.
• Performans gereksinimlerinin karşılandığını nasıl test edersiniz?
• Testte kalıp bilgisi azdır: saplamalar, hazır yanıtlar, regresyon testi çoğu insanın bilmediği kavramlardır. İşyerinizde kaç kişi birim testi hakkında bir kitap okuyor?

Yönetimi suçlayabileceğimiz tek şey, gereksinim özelliklerinin, teslim edilecek ürünün kalite düzeyinde nadiren herhangi bir gereksinimi içermesidir.

Patronunuz bir dahaki sefere bir süre tahmini yapmanızı istediğinde, bir birim testi yazmak için zamanı ekleyin ve ne olacağını görün.

Çoğu test hiçbir şeyi test etmez.
Bir fileopen () işlevi ve dosya yoksa başarısız olan ve dosya varsa başarılı olan bir birim testi yazarsınız. Harika! Şimdi BIG5 çince dosya adıyla çalışıp çalışmadığını kontrol ettiniz mi? bir NFS paylaşımında? bir USB anahtarındaki dosya ve UAC AÇIK durumda mı?

Sorun, birim testlerin, işlevi yazan aynı programcı tarafından, aynı varsayımlar kümesine ve aynı beceri düzeyiyle yazılmasıdır. Gerçekten işe yaraması için, testlerin başka biri tarafından, yalnızca kodu görmeden yayınlanan özelliklere göre yazılması gerekir. - Çoğu şirkette, teknik özelliklerin sadece yazılı hale getirilmesi bir atılım olacaktır!

Birim testleri, ayrı işlevlerin kodundaki hataları kontrol eder. Girdi / çıktıların iyi bilindiği ve iç yapının karmaşık olduğu, ancak çoğu durumda sadece zaman kaybı olduğu veri erişim katmanları, matematik kitaplıkları vb. İçin çalışabilirler.
Hatalar, kodun farklı bölümleri arasındaki veya işletim sistemi ile kullanıcı arasındaki etkileşimlerden kaynaklandığında başarısız olurlar. Yüksek / düşük DPI ayarlarının bir iletişim kutusunu bozması veya yabancı dil ayarının a '' değiştirmesi gibi sorunlar. ve ',' genellikle bulunmaz.

Birim testlerinin ROI'si üzerinde yapılan çalışmalar vardır - bu soruya bakın .

Birim testiyle ilgilenmeyen birçok geliştirici buldum. Başladığınızda her zaman küçük bir getirisi olan çok iş varmış gibi görünür. Kimse fazladan işe kaydolmak istemez ve bu yüzden direnirler. İnsanlar başladıktan sonra, genellikle şevkle buna bağlı kalırlar, ancak onları başlatmak zor olabilir.

Birim testinin benimsenmesi meselesinin yanı sıra, birim testi her zaman işe yaramaz, ancak genel olarak doğru uygulandığında öyle olduğunu düşünüyorum. Onları zayıf yapıya karşı savunmasız olmaktan kurtaran birim testleri hakkında özel bir şey yoktur.

Birim testlerinin maliyetleri vardır (oluşturma, bakım ve çalıştırma) ve yalnızca bu maliyetlerden daha fazla fayda sağladıkları takdirde değerlidir. Test oluşturma da diğerleri gibi bir beceridir, başarı için özel deneyim ve bilgi gerektirir. Yeterli deneyim olmadan, tecrübeli geliştiricilerin bile, düşük kaliteli, düşük değerli ve / veya değerli olmayan yüksek maliyetli birim testleri oluşturması çok kolaydır. Özellikle de bir birim testinin değerini yargılamanın ne kadar zor olabileceği düşünüldüğünde.

Ek olarak, birim testi kod kalitesini artırmanın yalnızca bir yoludur, ancak tek yol bu değildir. Bazı durumlarda ve bazı ekiplerde yazılım kalitesini artırmanın en etkili yolu olmayabilir.

Unutmayın ki ünite testine çok fazla çaba sarf etmek kaliteli yazılımın garantisi değildir. Ayrıca herhangi bir birim testi yapmadan en yüksek kalitede yazılım üretmek mümkündür.

Şirketim TDD veya Unit Testing ile gitmedi. Dürüst olmak gerekirse, bunu nasıl yapacağımızdan emin değiliz. Bunu CapitalizeString (), vb. Gibi aptal işlevler için yapabiliriz, ancak karmaşık nesneler içeren oldukça karmaşık sistemler için bunu nasıl yapacağımızı bilmiyoruz. Dahası, görüşülen kişilerin çoğunun ya sıfır deneyimi ya da sınırlı deneyimi vardır. Görünüşe göre Birim Testi, SO kalabalığından büyüktür, ancak mevcut çalışma havuzunda özellikle büyük değildir.

TDD ayrı bir konudur. Ahlaki olarak TDD'ye karşıyız. Kovboy kodlamacıları değiliz, ancak bunun bir projede yaratıcılığı ve esnekliği engellediğine inanıyoruz. Dahası, birim test fonksiyonunu yazan kodlayıcıya sahip olmak hiç mantıklı değil. Bir şey yaptığımda, aklıma gelen tüm uç durumları kodluyorum. İhtiyacım olan şey, kaçırmış olabileceğim şeyleri arayan başka bir beyin. Buna sahip değiliz. Ekipler küçük ve bağımsızdır.

Kısacası TDD'ye inanmıyoruz ama Unit Test yapmak istiyoruz. Bunu yapacak deneyime sahip değiliz ve onu kolayca bulamıyoruz.

En iyi uygulamalar doğrultusunda gerçekten hiçbir şey yapmayan birçok şirket var. Kod incelemesi yok, birim testi yok, test planı yok, hiçbir şey yok, sadece pantolonlarının koltuğunda.

Bunu, bir Sürekli Entegrasyon platformunu kullanmaları ve birim testleri geliştirmeleri için bir fırsat olarak değerlendirin! Olan güçleri etkilemenin ve aynı zamanda kodunuzun kalitesini ve kararlılığını artırmanın kolay yolu

Düzenleme: Sebep olarak, CI ve birim testini olağanüstü derecede kolaylaştıran mevcut araçların farkında olmadıklarını düşünüyorum.

Gördüğüm kadarıyla, pek çok şirket, pratik olarak birim testine uygun olmayan devasa, yüksek düzeyde bağlı kod tabanlarına sahip. Ayrıca düzgün test edilebilir gereksinimleri de yoktur, bu nedenle birim testleri "inşa edildiği gibi" fiili gereksinimlere karşı test eder.

Kötü birim testinin temel nedeninin tembellik olduğunu düşünmüyorum. Şirketim için, zaman kısıtlamaları ve "sadece hallet" tutumu, birim testi yapmak için en büyük caydırıcı unsurlardır. Ayrıca, sistemlerimizin başarısız olduğu yerler, "birim düzeyinde" değil, daha çok entegrasyon düzeyinde (hizmetler, veritabanı erişimleri, test için özel veriler gerektiren karmaşık sorgular) olma eğilimindedir. Bunları test etmek sadece daha zordur ve özelliği tamamlamak için zar zor yeterli zamanınız varsa, muhtemelen aynı anda herhangi bir yararlı test yapmak için zamanınız olmayacak.

Birim testi, derleyici gibi kod geliştirme iş akışının doğal bir parçası olmalıdır.

Ancak bu, yönetimi birim testinin faydaları konusunda eğitmeyi gerektirir. Genç geliştiricilerin böyle bir etkiye sahip olma şansı nispeten düşüktür. Bu nedenle, bir şirketin birim testinin savunucusu olup olmadığı, birim testinin savunucusu olan kıdemli bir geliştiriciye veya mimara sahip olup olmamasına bağlıdır.

Bunun "eksik olan nedir ve neden daha fazla şirket birim testi yapmıyor" sorunuzun cevabı olduğuna inanıyorum . :-)

Muhtemelen daha önce bahsettiğiniz birkaç şeyin birleşimidir. TDD'nin maliyet tasarruflarını ölçmek zordur. BT'nizi dış kaynak olarak kullanmak istiyorsanız, personeliniz için yılda ne kadar ödediğinizi mi yoksa sözleşme yapmanın maliyetini mi gösterebilirsiniz; çok somut. "Ah, bu test hata ayıklamam ve düzeltmem 4 saat sürecek bir hatayı yakaladı ..." nasıl denir?

Bazı yerlerin onu kullanmamasının nedeni, hem başlamak hem de devam etmek için çok fazla çalışma gerektirmesidir. Birim testleri yazmanın gerçek işlevselliği yazmak kadar zaman alması, bazı yöneticilere geliştiricinizin üretkenliğini yarıya indiriyormuşsunuz gibi görünüyor.

Bunun da ötesinde, bir ekip (veya bir başkasının) altyapıyı yerleştirmesi ve sürdürmesi gerekir.

Ve Alan'ın dediği gibi, pek çok yer en iyi uygulamaları kullanmıyor - sadece somut bir şey görmek istiyorlar.

Bence programcı bunu yapmaya başlamalı. Başlamak için birkaç basit testi, geliştirmenin bir parçası olarak gerekçelendirmek kolaydır.

Bir birim testi gibi bir şey, hızlı bir şekilde hata ayıklama işlemini gerçekleştirmek için neredeyse her zaman gereklidir. Testi başlatmanın doğru girişi ayarlamaktan, bir hata ayıklayıcı kesme noktası ayarlamaktan, uygulamayı başlatmaktan ne kadar hızlı olduğunu açıklayın.

Testi kodunuzda belgeleyin. Testin nerede olduğunu ve nasıl çalıştırılacağını açıklayan bir yorum koyun. Gelecek programcılar bunu görecek ve umarım test yayılacaktır!

Birim testi, çoğu insanın duyduğu kara kutu terimlerinden biridir, ancak bir birim testini tam olarak neyin oluşturduğunu, nereden başlayacağını, nasıl yazılacağını, testlerin nasıl çalıştırılacağını, tam olarak neyi test etmesi gerektiğini vb. . vs vs.

Çoğu durumda, emin olmayan geliştiricinin bunları gereksiz veya yalnızca "kurumsal düzeydeki geliştiricilerin" ihtiyaç duyduğu bir buzlanma olarak görüp atması daha kolaydır.

Birim testlerinin büyük bir hayranıyım ve ayrıca çeşitli müşteri türleri için sözleşme geliştirme projeleri yapan bir şirketin ortağıyım. Bir ay içinde farklı boyutlarda 3-4 farklı projeye değineceğiz.

Bir proje tek seferlik olacak gibi görünüyorsa, birim testine çok fazla yatırım yapmayacağım çünkü bu birim testi işim için karşılığını almıyor. Bu tür projelerde, emin olmadığım / aşina olmadığım veya sıkça değişebilecek şeyleri (kontrol etmediğim bir veri kaynağı için ayrıştırıcı gibi) birim test edeceğim.

Halbuki, uzun ömürlü olacağını bildiğim bir şey inşa ediyorsam, birden fazla yinelemeyle üzerinde çalışacağım daha büyük bir işse veya bir hata oluşursa müşterilerim üzerinde büyük bir etkisi olacak , Daha fazla birim testine yatırım yapacağım. Yine testlerin önceliği belirsiz / bilinmeyen / değişen kod etrafında döner.

Bence birim testleri, bir görevin karmaşıklığı ve işe yarayıp yaramayacakları etrafında dönmelidir. Kullanılmayacak ekstra kod yazmanın anlamı yok.

Benim deneyimlerime göre, gerçekten yazdığınız yazılıma bağlıdır. Bir UI için birim testleri yazmanın son derece zor olduğunu buldum. Sistemin yalnızca belirli bir girişi / çıkışı olan kısımları için birim testleri kullanıyorum.

Birim testini özlüyorum - bu hayatı kolaylaştırıyor.

Bu, bir şirketin birim testini benimsemesi için gerçekten yeterli bir neden değildir .

Yeterli bir neden "daha ucuz" (ve / veya "daha iyi") olabilir: Bu, birim testi hakkında kanıtlamak kadar kolay değildir.

Tek iyi neden, "birim testleri yazmak, geliştiricilerin zamanını en iyi şekilde kullanmaktır" olabilir ki bu, IMO'yu kanıtlamak için gerçekten zordur: ve bazı yerlerde, bazı yazılımlarda, bazı geliştiricilerde doğru olabilir ve başka yerlerde doğru olmayabilir.

Birim testleri dünyasını düşünmeyen pek çok geliştirici var: diğer test türlerinin (örneğin otomatik entegrasyon / işlevsel testler) daha ucuz ve daha değerli olabileceğini düşünenler de dahil olmak üzere, örneğin bunu düşünmeyen tek geliştirici ben miyim? t birim testleri gibi mi?

Elbette ideal dünyada, bir birim testi yaptırmaya karşı çıkamazsınız.

Bununla birlikte, bir birim testi yazıp yazmamanız birkaç şeye bağlıdır:

• Yazılım nasıl kullanılacak. Yalnızca kendiniz için yazılım yazıyor olsaydınız, birim testleri yazar mıydınız? Muhtemelen değil. Ticari olarak satılmak üzere önceden paketlenmiş bir yazılım yazıyorsanız, muhtemelen evet.

• Kodu kaç kişi koruyor .... Eğer sadece sizseniz, o zaman kodu hızlı bir şekilde çalıştırmanın hiçbir şeyin bozulmadığından emin olmak için yeterli olduğunu bir değişiklik yaptıktan sonra yeterince emin olacak kadar iyi biliyor olabilirsiniz. Eğer kodu orijinal olarak yazmamış olan diğer insanlar şimdi onu korumak zorunda kalırsa, bir birim testi, büyük bir düzeltmek için kodu güncellediklerinde (bu açıkça birim testinde yakalanmamıştı!) Onlara güven vermeye yardımcı olacaktır. .

• kod karmaşıklığı: yalnızca test gerektiren test kodu. Tek satırlık değişken atama yönteminin test edilmesi gerekmez. Birden çok yürütme yoluna sahip 50 satırlık bir yöntem muhtemelen bunu yapar.

• Pratik ticari ticari değerlendirmeler: Gerçek şu ki, birim testleri yazmak, bunu yapmamaktan daha uzun sürüyor. Ticari bir geleceği belirsiz olan prototip bir yazılım yazıyorsanız, o zaman yeterince iyi çalışan koda sahip olmak ile 2 hafta içinde daha iyi çalışan birim test edilmiş koda sahip olmak arasında yapılacak bir sonuç vardır. Bazen, yazılımın bir sonraki projeye benzeyecek kadar kısa bir rafı olup olmayacağını hızlıca (tüketici iştahı) öğrenmek işe yarar.

ve diğerlerinin de belirttiği gibi, bir test ancak onu yazan kişi kadar iyidir.

Bunun ana nedeni, birçok geliştiricinin ve geliştirme yöneticisinin birim testlerin var olduğuna veya bunların nasıl kullanılacağına dair bir fikre sahip olmamasıdır.

İkinci neden ise, birim testlerin (mantıklı bir şekilde) yalnızca bazı kalite standartlarını zaten karşılayan kodlarla kullanılabilmesidir. Muhtemelen, bazı mevcut kod tabanları bu kategoriye girmiyor.

Üçüncü neden tembellik ve / veya ucuzluktur.

Çünkü birim testleri yalnızca test edilebilir kod yazarsanız faydalıdır. Ve test edilebilir kod yazmak zordur. Ve insanlar tembel ve / veya ucuzdur.

DÜZENLEME: "tembel ve / veya ucuz" olarak nüanslı "tembel"; Bazı nadir durumlarda, insanlar aslında test yazma becerisine, kapasitesine ve iradesine sahiptir, ancak yapacakları başka bir şeyleri vardır, bu da alt çizgiyi daha doğrudan etkiler.

Sanırım sorunun bir kısmı, geliştiricilerin iş insanlarının aynı değerlere sahip olmasını ve "birim testi yapmalı mıyız, yapmamalı mıyız?" Cevabını gerçekten önemsemelerini beklemeleri. Montaj dili yerine üst düzey bir dil kullanmak için şirketten önceden onay almıyoruz - bu genellikle işi halletmenin mantıklı bir yoludur.

Noktasıdır biz (hepimiz konuda aynı bilgiye sahip olduğunu söylemek değil) arama yapmak için nitelikli tek olanlardır. Ayrıca, ekibiniz politika gereği birim testi yapmasa bile (veya günün yöntemini adlandırmasa bile) bu genellikle sizin bunu yapamaz.

Gerçek şu ki, yaptığımız şeylerin çoğunda YG'yi çok ince bir ayrıntı düzeyinde gerçekten kanıtlayamayız. Birim testinin neden bu mantıksız / tipik olmayan kanıt standardına uyulduğu beni aşıyor ...

İnsanlar tembeldir ve sadece mecbur bırakıldıklarında değişimi benimser.

2 sentim:

• Biraz eğitim ve disiplin gerektirir, ancak yeni mezunlar zaten uygun bilgilerle gelir.
• Test ek yükü daha iyi araçlarla azaltılabilir ve bu da oluyor (yeniden düzenleme vb.)

Yani bu sadece bir zaman meselesi.

Bob Martin'in iddia ettiği Martin-Coplien tartışması var:

"günümüzde, bir geliştiricinin bir birim testinde gerçekleştirmediği bir kod satırı göndermesi sorumsuzdur."

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Herkesi testte satmak istiyorsanız aşağıdakileri yapın:

1. Bir sürü test yazın.
2. Kodu değiştiren ve testlerinizden başarısız olan diğer geliştiricileri bilgilendirin.
3. Kodlarını düzeltirler.
4. Artık bu belirli hatalar olmadan serbest bırakabilirsiniz.

Bir yönetici bile bunu anlayabilir.

Şirketler, birçok web sitesinin kötü yazılmasıyla aynı nedenle birim testi yapmıyor - cehalet ve eski alışkanlıklara bağlı kalan insanlar. Şirketimde, birim testine başladığımızdan beri (Nunit ve Typemock ile ), daha yüksek kod kapsamına ulaşıyoruz ve yazılımı pazara daha kısa sürede yayınlıyoruz .

Çoğu iyi fikir gibi, benimsemenin de fikir kalitesinden çok örgütsel yol bağımlılığı ile ilgisi vardır.

Ürün gönderen çoğu şirkette, üst düzey bir QA başkanı ile önemli bir QA bölümü oluşturulmuştur. Test, QA ekibinin temelidir.

QA ekibinin birim test kodu yazması pek olası değildir, çünkü şirket genellikle QA ekibine ağır hizmet kodlayıcıları ile personel vermez.

Programlama ekibi, test kodu yazma konusunda isteksizdir çünkü bu, QA ekibiyle bir çelişki yaratır.

QA'nın ayrı bir görev işlevine dönüştürülmediği gruplarda Birim Testine daha fazla ilgi ve benimsenme olduğunu görüyorum.

Basit, birim testleri yazmak ve güncellemek paraya mal olur. Çoğu şirketin önceki yazılımlarının birim testleri yoktur ve yazmak için çok pahalıya mal olur. Yani bunu yapmazlar ve geliştirme sürecine zaman eklerler, böylece yeni özelliklere de eklemezler.

Çoğu şirket işe yaramaz. Belli ki sizin (veya benim) çalıştığınız kişi değil.