Birim testlerle gelişim arasındaki zaman farkı - test yok

İhtiyaçlara, aciliyete veya her ikisine de bağlı olarak, geliştirme zamanının genellikle proje başına 1-4 hafta arasında değiştiği, oldukça kısıtlı çalışma ortamına sahip solo bir geliştiriciyim. Herhangi bir zamanda, bazılarının birbirleriyle örtüşen zaman çizelgelerine sahip, yaklaşık 3-4 projeyi ele alıyorum.

Beklenildiği gibi, kod kalitesi zarar görüyor. Benim de resmi sınavım yok; genellikle biraz kırılıncaya kadar sistemin içinde yürümeye başlar. Sonuç olarak, düzeltmek zorunda olduğum önemli miktarda hata üretime kaçıyor ve sırayla diğer projelerimi geri çekiyor.

Bu, ünite testlerinin yapıldığı yerdir. Doğru yapıldığında, üretime kaçanlar, minimum seviyede olsa da, böcekleri saklamalıdır. Öte yandan, yazma testleri oldukça fazla zaman alabilir, bu da benim gibi zaman kısıtlamalı projelerle iyi gelmiyor.

Mesele şu ki, birim test kodunu test edilmemiş kod üzerine yazmak ne kadar zaman farkına sahip olacak ve proje kapsamı genişledikçe bu zaman farkı ölçeği nasıl ölçülecek?

Test yaptıktan sonra test yazmanın maliyeti daha fazla olur.

Bir böcek ne kadar uzun yaşarsa, düzeltmesi de o kadar pahalı olur.

Azalan verim yasası, hata bulunmadığından emin olmak için kendinizi zorbalık içinde test etmenizi sağlar.

Buda orta yolun bilgeliğini öğretti. Testler iyi. Çok iyi bir şey gibi bir şey var. Anahtar ne zaman dengesiz olduğunu söyleyebilir.

Testler olmadan yazdığınız her kod satırı, kodları yazmadan önce testleri yazmış olmanıza göre daha sonra test eklemek için önemli ölçüde daha yüksek maliyetlere sahip olacaktır.

Testlerin olmadığı her kod satırında hata ayıklamak veya yeniden yazmak çok daha zor olacaktır.

Yazdığınız her test zaman alacaktır.

Her hatanın düzeltilmesi zaman alacaktır.

Sadık, önce başarısız bir test yazmadan tek bir kod satırı yazmamanızı söyleyecektir. Test, beklediğiniz davranışa ulaşmanızı sağlar. Test davranışın aynı olduğunu kanıtladığından, sistemin geri kalanını etkilemek için endişelenmeden kodu hızlıca değiştirmenize olanak tanır.

Tüm bunları, testlerin özellik eklemediği gerçeğine karşı tartmalısınız. Üretim kodu özellikler ekler. Ve özellikleri faturaları öder.

Pragmatik konuşmak gerekirse, kaçabileceğim tüm testleri ekliyorum. İzleme testleri lehine olan yorumları görmezden geliyorum. Yaptığımı düşündüğüm şeyi yapmak için bile koduna güvenmiyorum. Testlere güvenirim. Ama ara sıra selamları atıp, şanslı olduklarını biliyordum.

Ancak, birçok başarılı kodlayıcı TDD yapmaz. Bu test etmedikleri anlamına gelmez. Sadece her kod satırının kendisine karşı otomatik bir test yapması konusunda takıntılı bir şekilde ısrarcı değiller. Bob Amca bile kullanıcı arayüzünü test etmediğini itiraf ediyor. Ayrıca, tüm mantığı kullanıcı arayüzünden çıkarmanız için ısrar ediyor.

Bir futbol metaforu olarak (bu Amerikan futbolu) TDD iyi bir yer oyunudur. Yalnızca bir kod yığını yazdığınız ve çalıştığını umduğunuzu test etmek için el ile geçen bir oyundur. Her ikisinde de iyi olabilirsin. Her ikisini de yapamazsan, kariyerin playoff yapmayacak. Her birini ne zaman seçeceğinizi öğrenene kadar superbowl yapmaz. Ancak belirli bir yönde bir dürtmeye ihtiyacınız varsa: yetkililer geçerken bana karşı daha sık görüşüyorlar.

TDD'yi denemek istiyorsanız, işte yapmayı denemeden önce pratik yapmanızı öneririm. TDD yarı yolda yapıldı, yarı yürekli ve yarı eşi bazılarının saygı duymamasının büyük bir nedeni. Bir bardak suyu diğerine dökmek gibi bir şey. Hızlı ve eksiksiz bir şekilde taahhüt ve işlem yapmazsanız, masanın her yerine su damlatıyorsunuz.

Cevapların geri kalanıyla aynı fikirdeyim, ancak zaman farkı sorusunun ne olduğunu doğrudan cevaplamak.

Roy Osherove kitabında , Birim Test Sanatı, İkinci Baskı, sayfa 200, bir takımın diğer takımın test ettiği diğer iki firmanın test ettiği iki farklı müşteri için benzer takımlarla (beceri bakımından) benzer büyüklükteki projeleri uygulamada bir vaka çalışması yaptı.

Sonuçları şöyle gibiydi:

Böylece bir projenin sonunda hem daha az zaman hem de daha az hata elde edersiniz. Bu elbette bir projenin ne kadar büyük olduğuna bağlıdır.

Bunu “gerçek dünya ortamında” çalıştığım bildiğim tek bir çalışma var : Test odaklı geliştirme yoluyla kalitenin iyileştirilmesi: dört sanayi ekibinin sonuçları ve deneyimleri . Bunu mantıklı bir şekilde yapmak pahalıdır, çünkü temel olarak aynı yazılımı iki kez (veya ideal olarak daha sık) benzer ekiplerle geliştirmeniz ve sonra hepsini bir başkasına atmanız gerektiği anlamına gelir.

Çalışmanın sonuçları, gelişim süresinde% 15 ile% 35 arasında (çoğu kez TDD eleştirmenleri tarafından alıntı yapılan 2x rakamına yakın hiçbir yerde) yakın bir artış ve salım öncesi kusur yoğunluğunda% 40 ile% 90 arasında bir düşüş olmuştur (! ). Tüm ekiplerin TDD ile önceden bir deneyime sahip olmadığına dikkat edin, böylece zaman içindeki artışın en azından kısmen öğrenmeye atfedilebileceği ve dolayısıyla zamanla daha da aşağıya ineceği varsayılabilir, ancak bu çalışma tarafından değerlendirilmedi.

Bu çalışmanın TDD ile ilgili olduğunu ve sorunuzun çok farklı şeyler olan birim testleriyle ilgili olduğunu, ancak bulabildiğim en yakın konudur.

İyi yapıldığında, yakalanan ekstraların faydaları göz önüne alınmadan bile birim testleriyle geliştirme daha hızlı olabilir.

Gerçek şu ki, kodumu derhal derhal çalıştıracak kadar basit bir kodlayıcı değilim. Kod yazarken / değiştirirken, düşündüğüm şeyi yaptığından emin olmak için kodu çalıştırmam gerekiyor. Bir projede, bunun neye benzemesi bekleniyor:

1. Kodu değiştir
2. Derleme uygulaması
3. Uygulamayı çalıştır
4. Uygulamaya giriş yap
5. Bir pencere aç
6. Başka bir pencere açmak için o pencereden bir öğe seçin
7. Bu pencerede bazı kontrolleri ayarlayın ve bir düğmeye tıklayın

Ve elbette, tüm bunlardan sonra, doğru bir şekilde yapmak için genellikle birkaç tur atıldı.

Şimdi, birim testleri kullanıyorsam? Sonra süreç daha çok benziyor:

1. Bir test yaz
2. Testleri çalıştırın, beklenen şekilde başarısız olduğundan emin olun
3. Kod yaz
4. Testleri tekrar çalıştırın, geçtiğini görün

Bu, uygulamanın manuel olarak test edilmesinden sonra daha kolay ve hızlıdır. Hala uygulamayı el ile çalıştırmam gerekiyor (bu yüzden aslında hiç çalışmayan bir işe girdiğimde aptal görünmüyorum), ama çoğunlukla ben zaten sapkınlıkları çözdüm ve sadece bu noktada doğrulama. Genelde, kaydettiğimde testlerimi otomatik olarak tekrar gösteren bir program kullanarak bu döngüyü daha da sıkı hale getiririm.

Ancak, bu test dostu bir kod tabanında çalışmanıza bağlıdır. Birçok proje, birçok teste sahip olanlar bile, yazma testlerini zorlaştırır. Ancak, üzerinde çalışırsanız, otomatik testlerle test etmenin daha kolay olduğu bir manuel kod testine sahip bir kod tabanınız olabilir. Bonus olarak, otomatik testleri etrafta tutabilir ve gerilemeleri önlemek için koşturmaya devam edebilirsiniz.

Halihazırda birçok cevap olmasına rağmen, bunlar biraz tekrarlayıcıdır ve farklı bir alış veriş yapmak istiyorum. Birim testleri, yalnızca ve eğer işletme değerini arttırırlarsa değerlidir . Testlerin hatırı için test (önemsiz veya tautolojik testler) veya bazı rasgele metriklere (kod kapsamı gibi) çarpmak, kargo-kült programlamadır.

Testler sadece onları yazmak için gerekli olan zamanda değil aynı zamanda bakım açısından da maliyetlidir. Test ettikleri kodla senkronize tutulmaları gerekir ya da değersizdirler. Her değişiklik için onları çalıştırmanın zaman maliyetinden bahsetmiyorum bile. Bu bir anlaşma kırıcı değil (ya da gerçekten gerekli olanları yapmamak için bir bahane) değildir, ancak maliyet-fayda analizine dahil edilmesi gerekir.

Bu nedenle, bir işlevi / yöntemi test edip etmeyeceğine (veya ne türden) karar verirken sorulacak soru, kendinize 'bu testle hangi son kullanıcı değerini yaratacağım / koruyacağım?' Diye sorun. Bu soruyu yanıtlayamazsanız, başınızın üstünden , o zaman bu test yazma / sürdürme maliyetine değmez. (veya bir olan sorun alanını, anlamıyorum waaaay testlerin eksikliği daha büyük sorun).

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

Bu, çalışmakta olduğunuz kodun karmaşıklığına ve şekline olduğu kadar kişiye de bağlıdır.

Benim için, çoğu projede, birim testleri yazmak, çalışmaları% 25 daha hızlı tamamladığım anlamına gelir. Evet, testleri yazma zamanı dahil bile.

Çünkü işin aslı , kodu yazarken yazılımın yapılmadığıdır . Müşteriye sevk ettiğinizde yapılır ve mutlu olurlar. Birim testleri, bugüne kadar en fazla böcek yakalamak, hata ayıklamak için hataların çoğunu izole etmek ve kodun iyi olduğuna dair güven kazanmak için bildiğim en etkili yöntemdir. Bunları zaten yapmak zorundasın, o yüzden iyi yap.

Mesele şu ki, birim test kodunu test edilmemiş kod üzerine yazmak ne kadar zaman farkına sahip olacak ve proje kapsamı genişledikçe bu zaman farkı ölçeği nasıl ölçülecek?

Projenin yaşı arttıkça sorun daha da kötüye gidiyor: çünkü ne zaman yeni işlevler eklerseniz ve / veya ne zaman mevcut uygulamayı yeniden uygularsanız, hala çalışmasını sağlamak için daha önce test edilenleri tekrar test etmeniz gerekir. Bu nedenle, uzun ömürlü (çok yıllı) bir proje için, yalnızca işlevselliği test etmek değil, aynı zamanda 100 kez ve daha fazla tekrar test etmeniz gerekebilir. Bu nedenle otomatikleştirilmiş testlerden faydalanabilirsiniz . Ancak, IMO, bunlar otomatik birim testleri yerine, otomatik sistem testleri ise, yeterince iyidir (hatta daha iyi).

İkinci bir sorun, erken yakalanmadıkları takdirde böceklerin bulunması ve düzeltilmesi daha zor olabilir. Örneğin, sistemde bir hata varsa ve en son değişikliğinizi yapmadan önce mükemmel şekilde çalıştığını biliyorum, o zaman hatayı nasıl tanıttığını görmek için dikkatimi en son değişikliğinize odaklayacağım. Ancak, en son değişikliğinizi yapmadan önce sistemin çalıştığını bilmiyorsam (çünkü sistem en son değişikliğinizden önce düzgün bir şekilde test edilmedi), o zaman hata herhangi bir yerde olabilir.

Yukarıdakiler özellikle derin koda uygulanır ve sığ koda daha az uygulanır; örneğin, yeni sayfaların varolan sayfaları etkileme olasılığı düşük olan yeni web sayfaları ekleme.

Sonuç olarak, düzeltmek zorunda olduğum önemli miktarda hata üretime kaçıyor ve sırayla diğer projelerimi geri çekiyor.

Tecrübelerime göre bu kabul edilemez olurdu ve bu yüzden yanlış soruyu soruyorsun. Testlerin kalkınmayı daha hızlı yapıp yapmayacağını sormak yerine, kalkınmayı daha hatasız hale getirecek şeyleri sormalısınız.

Daha iyi bir soru olabilir:

• Ünite testi, üretmekte olduğunuz "önemli miktarda hata" dan kaçınmanız gereken doğru türde bir test midir?
• Önerilecek veya bunun yerine önerilecek başka kalite kontrol / geliştirme mekanizmaları (ünite testlerinin dışında) var mı?

Öğrenme iki aşamalı bir süreçtir: yeterince iyi yapmayı öğrenin, sonra daha hızlı yapmayı öğrenin.

Dikkate alınması gereken bazı hususlar, diğer cevaplarda belirtilmeyen.

• Ekstra Fayda / Ekstra Maliyet, en küçük olanları yazma deneyimine bağlıdır.
  • ilk birim test projemde ekstra maliyetler arttı çünkü çok fazla şey öğrenmek zorunda kaldım ve çok fazla hata yaptım.
  • tdd ile 10 yıllık deneyimden sonra, testleri önceden yazmak için% 25 daha fazla kodlama süresine ihtiyacım var.
• Daha fazla tdd modülü ile manuel-gui-test ve entegrasyon testlerine hala ihtiyaç var
• tdd sadece baştan yapıldığında çalışır.
  • Mevcut, büyütülmüş bir projeye tdd uygulamak pahalı / zordur. Ancak bunun yerine regresyon testlerini uygulayabilirsiniz.
• otomatik testler (son testler ve diğer tür testler) çalışmalarını sürdürmek için bakım const gerektirir.
  • kopyala ve yapıştır yoluyla test oluşturmuş olmak testcode bakımını pahalı hale getirebilir.
  • Büyüyen deneyime sahip test kodu daha modüler ve bakımı daha kolay hale gelir.
• Büyüme deneyimiyle, otomatik testler oluşturmanın ne zaman değerli olduğu hissine kapılacaksınız.
  • Örneğin, en basit olmayan alıcı / ayarlayıcı / sarmalayıcıların hiçbir yararı yoktur.
  • gui üzerinden otomatik testler yazmıyorum
  • işyerinin test edilebilmesine dikkat ediyorum

özet

Tdd ile başlarken, “zaman kısıtlı çalışma ortamı” altında olduğunuz sürece “pahalıdan yararsız” durumdayken, “pahalı yöneticilerden” kurtulmanızı söyleyen “akıllı yöneticiler” varsa, “maliyetten daha fazla yarar” durumuna ulaşmak zorlaşır. malzeme denemesi "

Not: "ünite testi" ile "izolasyon modülleri izole edilmiştir" anlamına gelir.

Not: "regresyon testi" ile demek istediğim

• çıktı metni üreten bir kod yazın.
• Üretimin sonucunun hala aynı olduğunu doğrulayan bir miktar "regresyon testi" kodu yazınız.
• Regresyon testi sonuç ne zaman değiştiğinde size haber verir (ki bu iyi olabilir veya yeni bir hatanın göstergesi olabilir)
• “regresyon testi” fikri onay testlerine benzer
  • ... sonuçların fotoğrafını çekmek ve değişmediklerini teyit etmek.

Programcılar, çoğu işi yapan insanlarda olduğu gibi, bunu tamamlamanın ne kadar sürdüğünü hafife alır. Bunu akılda tutarak, bir test yazmak için 10 dakika harcamak, gerçekte zamanlarca kod yazarken harcadığınız zamana bakabilir, o zaman test sırasında yaptığınız işlev adı ve parametreleri ile gelmek için harcayacaksınız. . Bu bir TDD senaryosudur.

Test yazmamak, kredi kartı almak gibi bir şey; daha fazla harcama ya da daha fazla kod yazma eğilimindeyiz. Daha fazla kodda daha fazla hata var.

Toplam kod kapsamı olup olmadığına veya hiçbiri olmadığına karar vermek yerine, başvurunuzun kritik ve karmaşık kısmına odaklanmanızı ve orada testler yaptırmanızı öneririm. Bir bankacılık uygulamasında, bu faiz hesaplama olabilir. Bir motor teşhis aleti karmaşık kalibrasyon protokollerine sahip olabilir. Bir proje üzerinde çalışıyorsanız, muhtemelen ne olduğunu ve böceklerin nerede olduğunu biliyorsunuzdur.

Yavaş yavaş başla. Yargılamadan önce biraz akıcılık oluşturun. Her zaman durabilirsin.

TDD'yi ve diğer test metodolojilerini destekleyen uzun bir Programcılar kurulu geçmişi var, tartışmalarını hatırlamayacağım ve onlarla aynı fikirdeyim;

• Test, bağlama bağlı olarak eşit derecede uygun ve verimli değildir. Web yazılımını geliştiriyorum, tüm kullanıcı arayüzünü test etmek için bir programınız olup olmadığını söyleyin ... şu anda excel makroları programlıyorum, gerçekten VBA'da bir test modülü geliştirmeli miyim?
• Test yazılımının yazılması ve sürdürülmesi, kısa vadede sayılan gerçek bir iştir (daha uzun vadede karşılığını verir). İlgili testleri yazmak ayrıca almak için bir uzmanlıktır.
• Takım olarak çalışmak ve yalnız çalışmak aynı test şartlarına sahip değildir çünkü takımda yazmadığınız kodu doğrulamanız, anlamanız ve iletmeniz gerekir.

Testin iyi olduğunu söyleyebilirim, ancak erken test ettiğinizden ve kazancın nerede olduğunu test ettiğinizden emin olun.

TDD'nin gözardı edilen bir yararı, testlerin değişiklik yaptığınızda yeni hatalar ortaya koymadığınızdan emin olmak için bir güvence görevi görmesidir.

TDD yaklaşımı şüphesiz başlangıçta daha fazla zaman alır ancak paketlenme noktası daha az kod yazmanız anlamına gelir; Tabi olarak dahil ettiğiniz tüm bu ziller ve ıslık, elbette kod tabanına girmez.

Swordfish filminde, hafızanın işe yaraması durumunda bir korsanın kafasına silahla çalışmak zorunda kaldığı ve başkalarının dikkatini dağıttığı bir sahne var. Mesele şu ki, baş boşluğunuz koddayken çalışmak çok daha kolaydır ve bir müşteri sizi çığlık atarken ve diğer önceliklerin sıkıştığı sırada aylar süresinden ziyade yanınızda vaktiniz olur.

Geliştiriciler daha sonra hataları düzeltmenin daha maliyetli olduğunu anlıyorlar, ancak bunu kafasına çeviriyorlar. Şimdi nasıl kodladığınızı kodlamak için günde 500 dolar veya TDD biçiminde yazdıysanız 1000 dolar ödenirse, sizi 2. teklifi yapan kişinin elini ısırırsınız. Testleri bir angarya olarak görmeyi bırakıp para biriktirici olarak görürseniz daha iyi olursunuz.

Deneyiminizle ilgili olabilirim - kod tabanımızın neredeyse hiçbir testi yoktu ve çoğunlukla denenemezdi. Gerçekten bir şey geliştirmek için yaş aldı ve prodüksiyonları tamir etmek, yeni özelliklerden değerli zamanlar aldı.

Kısmi bir yeniden yazma için, tüm temel işlevsellik için testler yazmaya söz verdim. Başlangıçta, çok daha uzun sürdü ve üretkenliğim dikkat çekiyordu, ancak sonrasında verimim hiç olmadığı kadar iyiydi.

Bu iyileştirmenin bir kısmı, daha az kesintiye neden olan daha az üretim hatamın olmasıydı -> Herhangi bir zamanda daha iyi odaklandım.

Dahası, testlerde VE hata ayıklama kodunu izolasyonda gerçekten test etmenin yetersizliği - bir test paketi, manuel kurulum dışında, örneğin uygulamanızı başlatma ve ekrana gidip bir şey yapma ... birkaç düzine kez

Ancak başlangıçta verimlilikte bir düşüş olduğuna dikkat edin, bu nedenle zaman baskısının zaten delice olmadığı bazı projeler için test yapmaya başlayın. Ayrıca, bir greenfield projesinde başlatmaya çalışın, birim test eski kodu çok zordur ve iyi bir test takımının nasıl göründüğünü bildiğinizde size yardımcı olur.

Sadece önceki cevapları tamamlamak için: test etmenin bir amaç olmadığını unutmayın. Testler yapmanın amacı, başvurunuzun beklenmedik bağlamlar içinde evrim yoluyla beklendiği gibi davranmasıdır.

Bu nedenle, test yazmak bir işletmenin tüm son noktalarının tüm davranışlarını kanıtlamak anlamına gelmez. Bu yaygın bir hatadır. Birçok geliştirici, tüm işlevleri / nesneleri / yöntemleri / özellikleri / vb. Test etmeleri gerektiğini düşünüyor. Bu, yüksek bir iş yüküne ve bir sürü alakasız kod ve testlere yol açar. Bu yaklaşım, çoğu geliştiricinin bütünsel davranışın farkında olmadığı, ancak yalnızca etkileşim alanlarını görebildiği büyük projelerde yaygındır.

Seyrek kaynaklar ve testlerle uğraşırken doğru yaklaşım oldukça açıktır ve sağduyuludur, ancak genel olarak resmileştirilemez: test geliştirme kaynaklarını ilk önce üst düzey işlevselliklere yatırın ve kademeli olarak spesifikliklere inin . Bu, bir noktada, yalnız bir geliştirici olarak, yalnızca birim testine değil, işlevsellik / entegrasyon / etc'ye odaklanacağınız anlamına gelir. Test ve zaman kaynaklarına bağlı olarak, planladığınız ve düşündüğünüz gibi kademeli olarak temel üniter fonksiyonlara. Yüksek seviye testleri, düşük seviye / üniter testleri ele almak ve sahip olduğunuz kaynaklara göre test geliştirme stratejinizi planlamak için gerekli bilgileri sağlayacaktır.

Örneğin, bir işlem zincirini önce kara kutu olarak test etmek istiyorsunuz. Zincirin bir üyesinin davranışının aşırı bir durum olarak değerlendirilmediği için başarısız olduğunu tespit ederseniz, sadece bu üyeye değil diğerlerine de işlevselliği garanti eden testleri yazarsınız. O zaman sen teslim et. Bir sonraki döngü için, bazen ağın başarısız olduğunu tespit edersiniz. Böylece, bu konuyu ele alan ve savunmasız olabilecek modüller üzerine testler yazıyorsunuz. Ve bunun gibi.