Ünite testinin yapılmaması ne zaman uygundur?

Küçük bir şirkette solo geliştirici olarak çalışıyorum. Aslında şirketteki tek geliştiriciyim. Düzenli olarak yazıp sürdürdüğüm birkaç (nispeten) büyük projem var ve bunların hiçbirinin onları destekleyecek testleri yok. Yeni projelere başladığımda, TDD yaklaşımını denemem gerekip gerekmediğini sık sık merak ediyorum. Kulağa iyi bir fikir gibi geliyor, ama dürüst olmak gerekirse, söz konusu ek işi asla haklı çıkaramam.

Tasarımımda ileriyi düşünmek için çok çalışıyorum. Kesinlikle bir gün başka bir geliştiricinin kodumu sürdürmesi veya en azından sorunu gidermesi gerektiğinin farkındayım. İşleri olabildiğince basit tutuyorum ve kavraması zor olan şeyleri yorumluyorum ve belgeliyorum. Gerçek şu ki, bu projeler o kadar büyük ya da karmaşık değil ki, iyi bir geliştirici onları anlamak için mücadele edecek.

Testlerde gördüğüm örneklerin çoğu, kodun tüm yönlerini kapsayan, minutiye iniyor. Tek geliştirici olduğumdan ve tüm projedeki koda çok yaklaştığım için, elle yazıp test test desenini takip etmek çok daha verimli. Ayrıca, testlerin sürdürülmesinin bir projeye kayda değer miktarda sürüklenme katacağı kadar, gereksinimlerin ve özelliklerin yeterince sık değiştiğini de tespit ediyorum. İş ihtiyaçlarını çözmek için harcanabilecek zaman.

Böylece her seferinde aynı sonuca varıyorum. Yatırım getirisi çok düşük.

Bir algoritmayı doğru bir şekilde yazdığımdan emin olmak için ara sıra birkaç test kurdum, örneğin işe alım tarihine göre birisinin şirkette bulunduğu yıl sayısını hesaplamak gibi. Ancak kod kapsamı açısından kodumun yaklaşık% 1'ini karşıladım.

Benim durumumda, birim testini düzenli bir uygulama yapmanın bir yolunu bulmaya devam eder misiniz, yoksa bu genel giderden kaçınmakta haklı mıyım?

GÜNCELLEME: Durumumla ilgili bıraktığım birkaç şey: Projelerimin hepsi web uygulamaları. Tüm kodlarımı kapsayacak şekilde, otomatik UI testleri kullanmak zorunda kalacağım ve bu, manuel testlerden daha fazla fayda göremediğim bir alan.

Testlerde gördüğüm örneklerin çoğu, kodun tüm yönlerini kapsayan, minutiye iniyor.

Yani? Her şeyi test etmek zorunda değilsin . Sadece ilgili şeyler.

Tek geliştirici olduğumdan ve tüm projedeki koda çok yaklaştığım için, elle yazıp test test desenini takip etmek çok daha verimli.

Bu aslında yanlış. Daha verimli değil. Bu gerçekten sadece bir alışkanlık.

Diğer solo geliştiricilerin yaptığı bir taslak veya taslak yazmak, test senaryolarını yazmak ve sonra taslakları son kodla doldurmaktır.

Bu çok, çok verimli.

Ayrıca, testlerin sürdürülmesinin bir projeye kayda değer miktarda sürüklenme katacağı kadar, gereksinimlerin ve özelliklerin yeterince sık değiştiğini de tespit ediyorum.

Bu da yanlış. Testler sürükle değil. Gereksinimler değişiklikleri sürükle.

Gereksinimleri yansıtmak için testleri düzeltmelisiniz. Minutia veya üst düzey olup olmadığı; ilk yazılı ya da son yazılı.

Testler geçene kadar kod yapılmamıştır. Yazılımın tek evrensel gerçeği budur.

Sınırlı bir "burada" kabul testi olabilir.

Veya bazı birim testlerine girebilirsiniz.

Ya da ikisine birden sahip olabilirsin.

Ancak ne yaparsanız yapın, yazılımın çalıştığını gösteren bir test her zaman vardır.

Biraz formalite ve hoş bir birim test aracı paketi bu testi çok daha faydalı kılar.

Bir göz bağı içinde çalışabilecek ve yeşil veya kırmızı bir ışığı aydınlatabilecek bir testlerinizin olduğunu hayal edin. Bu test grubunun her şeyi test ettiğini hayal edin ! Bir test grubunu çalıştırmak için tek yapmanız gereken, ^ T yazmanız olduğunu düşünün. Bu size hangi gücü verir?

Bir şeyi kırma korkusu olmadan kodda değişiklik yapabilir misiniz? Eski bir özelliği bozma korkusu olmadan yeni bir özellik ekleyebilir misiniz? Dağınık kodu, hasar verme korkusu olmadan hızlı bir şekilde temizleyebilir misiniz?

Evet, bütün bunları yapabilirsin! Ve zamanla kodunuza ne olacak? Temizleyici ve temizleyici olur, çünkü temizleme riski yoktur.

Omzunda küçük bir peri olduğunu hayal edelim. Her ne zaman bir kod satırı yazsanız, peri, bu kod satırının yapmayı amaçladığı şeyi test eden test odasına bir şey eklerdi. Her birkaç saniyede ^ T tuşuna basabilir ve yazdığınız son kod satırının çalıştığını görebilirsiniz.

Sizce ne kadar hata ayıklama yapacaksınız?

Bu fantezi gibi geliyorsa haklısınız. Fakat gerçek pek farklı değil. Göz kaşını birkaç saniye, perisi de TDD disipliniyle değiştirin ve hemen hemen anladınız.

Bir yıl önce kurduğunuz bir sisteme geri döndüğünüzü ve merkezi nesnelerden birinin nasıl oluşturulduğunu unuttuğunuzu varsayalım. Bu nesneyi, yaratıldığı her şekilde yaratan testler var. Bu testleri okuyabilir ve hafızanızı yükseltebilirsiniz. API çağırmanız mı gerekiyor? Bu API'yi her çağrıldığı şekilde çağıran testler var. Bu testler, anladığınız bir dilde yazılmış küçük belgelerdir . Tamamen belirsizler. Onlar yürütmek için çok resmi. Ve uygulama ile senkronizasyondan çıkamıyorlar!

Yatırım yapmaya değmez mi? Şaka yapıyor olmalısın! Nasıl biri bu test paketini İSTEMEZ? Kendine bir iyilik yap ve saçma sapanlığı kesmeyi bırak. TDD'yi iyi yapmayı öğrenin ve ne kadar hızlı gittiğinizi ve kodunuzun ne kadar daha temiz olduğunu izleyin.

Yaptığınız hata, testi anında geri dönüşü olmayan bir zaman yatırımı olarak görüyor olmanızdır. Bu şekilde çalışmak zorunda değil.

İlk olarak, testler yazmak size gerçekten kodunuzun bu bölümünün ne yapması gerektiğine odaklanır.

İkincisi, bunları çalıştırmak, aksi takdirde testte ortaya çıkacak olan hataları ortaya çıkarır.

Üçüncüsü onları çalıştırmak bazen testten başka türlü çıkmayan hataları ortaya çıkarır ve daha sonra sizi gerçekten üretimdeki kıçtan ısırır.

Dördüncüsü, çalışan bir sistemle bir hataya çarptıysanız ve bunun için bir birim testi oluşturursanız, bu hatayı daha sonra tekrar tanıtamazsınız. Bu gerçekten büyük bir yardım olabilir. Yeniden girilen hatalar yaygın ve çok can sıkıcıdır.

Beşinci olarak, bir başkasına kodu teslim etmeniz gerekirse, bir test paketi hayatlarını çok kolaylaştıracaktır. Ayrıca, bir projeyi görmezden gelindi ve birkaç yıl sonra geri döndüyseniz, artık o kadar yakın olmayacaksınız ve bu size de yardımcı olacaktır.

Tecrübelerim sürekli olarak bir projenin geliştirilmesi boyunca, iyi birim testlerinin yapılmasının süreci daha hızlı ve daha güvenilir hale getirdiği yönünde olmuştur.

JUnit'in (Java Ünitesi test çerçevesi) adamları, test edilmesi çok basitse test etmediği felsefesine sahiptir . Oldukça pragmatik olduğu için En İyi Uygulamalar SSS bölümünü okumanı şiddetle tavsiye ediyorum .

TDD, yazılımınızı yazmak için farklı bir işlemdir. Ünite testinin ardındaki temel öncül kodda hata ayıklayıcıda daha az zaman harcayacağınız ve kod değişikliğinizin yanlışlıkla sistemdeki başka bir şeyi bozup bozmadığını daha çabuk çözmenizdir. Bu TDD ile uyuyor. TDD döngüsü şöyledir:

1. Bir test yaz
2. Başarısızlığını izleyin (yapacak bir şeyin olduğunu kanıtla)
3. Sadece sınavın geçmesi için gerekenleri yazın - daha fazla değil.
4. Geçişini izle (yay!)
5. Refactor (daha iyi hale getirin)
6. Yıkayın, durulayın ve tekrarlayın

TDD'yi uygulamada daha az belirgin olan şey, yazma kodunuzun şeklini değiştirmesidir . Kodun çalıştığını test etmek / doğrulamak konusunda kendinizi düşünmeye zorlayarak, test edilebilir bir kod yazıyorsunuzdur. Birim testinden bahsettiğimiz için, bu genellikle kodunuzun daha modüler hale geldiği anlamına gelir. Bana göre, modüler ve test edilebilir kod, büyük bir kazanç ön cephesidir.

Şimdi, C # özellikleri gibi şeyleri test etmeniz mi gerekiyor? Bunun gibi tanımlanmış bir özellik hayal edin:

bool IsWorthTesting {get; set;}

Cevap, "hayır" olacaktır, test etmeye değmez çünkü bu noktada dil özelliğini test ediyorsunuz. Sadece C # platformu adamlarının doğru anladığından emin olun. Ayrıca, başarısız olursa, düzeltmek için ne yapabilirsin ?

Ayrıca, kodunuzun bazı kısımları olduğunu göreceksiniz, düzgün şekilde test etmek için çok fazla çaba harcayacaksınız. Bu yapma, ancak zor bir problem tarafından kullanılan / kullanılan kodu test ettiğinizden emin olun:

• Yalnızca bir yükleme kötüye giderse gerçekleşebilecek denetlenen istisnalar. Java'da bunlardan bir ton var. Yüklenmiş dosyaları hacklemeden başarısız olmasına rağmen bir catch bloğu yazmanız veya işaretli istisnayı bildirmeniz gerekir.
• Kullanıcı arayüzleri. Denetimi kontrol altında bulmak ve bir kullanıcının eylemlerini simüle etmek için doğru olayları çağırmak çok zordur ve bazı durumlarda imkansızdır. Bununla birlikte, Model / Görünüm / Denetleyici modelini kullanırsanız, model ve denetleyicilerinizin test edildiğinden emin olabilir ve görünüm kısmını manuel teste bırakabilirsiniz.
• İstemci / sunucu etkileşimleri. Bu artık bir birim testi değildir ve şimdi bir entegrasyon testidir. Kablo üzerinden mesaj gönderip alan tüm parçaları yazın, ancak kablo üzerinden geçmeyin. İyi bir yaklaşım, tel üzerinden gerçek haberleşmeden bahseden kodun sorumluluğunu azaltmaktır. Ünite test kodunuzda, servislerin beklediğiniz gibi davrandığından emin olmak için iletişim nesnelerini alay edin.

İster inanın ister inanmayın, TDD sürdürülebilir bir gelişim temposuna girmenize yardımcı olacaktır. Bu sihir yüzünden değil, sıkı bir geri bildirim döngüsünüz olduğu ve gerçekten çok aptalca hataları yakalayabildiğiniz için. Bu hataları düzeltmenin maliyeti esasen sabittir (en azından planlama amacıyla yeterlidir) çünkü küçük hatalar asla büyük hatalar olarak ortaya çıkmaz. Bunu, kodlama saldırısı / hata ayıklama temizleme sprintlerinin kayma niteliğiyle karşılaştırın.

Test maliyetini böcek maliyetleriyle dengelemeniz gerekir.

Bir dosyayı açan bir fonksiyon için 10 satırlık bir ünite testi yazmak, arızanın "dosya bulunamadı" olduğu anlamsızdır.

Karmaşık bir veri yapısına karmaşık bir şey yapan bir işlev - daha sonra açıkça evet.

Zor bit, arada. Ancak birim testlerin gerçek değerinin belirli bir işlevi test etmediğini, aralarındaki zor etkileşimi test ettiğini unutmayın. Bu nedenle, bir bit koddaki değişikliğin, 1000 satır ötedeki farklı bir modüldeki bazı işlevleri bozduğunu belirten bir birim testi, kahvede ağırlığına değer.

Test etmek kumardır.

Bir test oluşturmak, bir birimdeki hataların maliyetinin bu testle (şimdi ve gelecekteki tüm kod revizyonları sırasında) yakalanmayan ve bunları yakalamayan testin geliştirme maliyetinden daha yüksek olduğu bir bahisdir. Bu test geliştirme maliyetleri, ek test mühendisliği için maaş bordrosu, piyasaya sürülen ek süre, başka şeyleri kodlamamaktan kaynaklanan kayıp fırsat maliyetleri vb.

Her bahis gibi, bazen kazanırsın, bazen kaybedersin.

Bazen çok daha az hata içeren geç yazılımlar, önce piyasaya çıkan hızlı ancak buggy işlerinden kazanıyor. Bazen tam tersi. Kendi alanınızdaki istatistiklere ve ne kadar yönetimin kumar oynamak istediğine bakmalısınız.

Bazı hata türlerinin, ek spesifik testler oluşturmak için zaman ayırmaya değmeyecek şekilde istatistiksel olarak değersiz olması nedeniyle, herhangi bir erken akıl yürütme testinden çıkması veya yapılması pek mümkün olmayabilir. Ancak bazen bir böceğin bedeli o kadar büyüktür (tıbbi, nükleer, vb.), Bir şirketin (sigorta satın almaya benzer) kaybedilen bir bahis alması gerekir. Birçok uygulamanın böylesine yüksek bir başarısızlık maliyeti yoktur ve bu nedenle yüksek ekonomik olmayan sigorta kapsamına ihtiyaç duymaz. Diğerleri yapar.

Tavsiyem sadece düzgün çalışmak istediğiniz kodu test etmektir.

Hatalı olmak ve yollarda sizin için sorunlara neden olmak istediğiniz kodu test etmeyin.

TDD yaklaşımını denemem gerekip gerekmediğini sık sık merak ediyorum. Kulağa iyi bir fikir gibi geliyor, ama dürüst olmak gerekirse, söz konusu ek işi asla haklı çıkaramam.

TDD ve Ünite Testi aynı şey değildir.

Kod yazabilir, daha sonra birim testleri ekleyebilirsiniz. Bu TDD değil ve bir sürü ekstra iş.

TDD, Kırmızı Işık döngüsünde kodlama uygulamasıdır. Yeşil ışık. Refactor yinelemeleri.

Bu, henüz mevcut olmayan kodlar için test yazmak, testlerin başarısız olduğunu izlemek, testlerin çalışmasını sağlamak için kodu sabitlemek ve ardından kodu "doğru" yapmak anlamına gelir. Bu genellikle işinizi kurtarır

TDD'nin avantajlarından biri, önemsiz şeyler hakkında düşünme ihtiyacını azalttığıdır. Tek tek hataları gibi şeyler kaybolur. Döndüğü listenin 0'dan mı yoksa 1'den mi başladığını bulmak için API belgelerine göz atmanız gerekmez.

Neredeyse her şeyi test ettiğimiz bir sistem üzerinde çalıştım. Testlerde dikkat çekici uygulamalar PDF ve XLS çıktı kodlarıydı.

Neden? Veri toplayan parçaları test ettik ve çıktıyı oluşturmak için kullanılan modeli oluşturduk. Ayrıca, modelin hangi parçalarının PDF dosyalarına gideceğini belirleyen parçaları da test ettik. PDF'nin iyi görünüp görünmediğini test edemedik çünkü bu tamamen özneldi. Bir PDF'deki tüm bölümlerin tipik bir kullanıcı tarafından okunabilir olduğunu test edemedik, çünkü bu da özneldi. Veya çubuk ve pasta grafikler arasındaki seçim veri kümesi için doğruysa.

Çıktı subjektif olacaksa, çabaya değer ne yapabileceğinizi çok az birim test var.

Birçok şey için, 'sonra yaz ve el ile test' birkaç test yazmaktan daha fazla zaman alır. Zaman tasarrufu, bu testleri istediği zaman yeniden yapabilmekten kaynaklanıyor.

Bir düşünün: Testlerinizle ilgili iyi bir özellik kapsamınız varsa (kod kapsamı ile karıştırılmaması gereken) ve 10 özelliğe sahip olduğunuzu varsayalım - bir düğmeyi tıkladığınızda kabaca, 10 testinizi tekrar yaptığınız anlamına gelir ... Arkanıza yaslanıp kahvenizi yudumlarken.

Ayrıca yok olması minutae test etmek. Nitty gritty ayrıntılarına düşmek istemiyorsanız, özelliklerinizi kapsayan entegrasyon testleri yazabilirsiniz ... IMO, bazı ünite testleri, kodu değil dili ve platformu test ederken çok iyi bir şekilde test edildi.

TL; DR Gerçekten hiç uygun değil çünkü faydalar çok iyi.

Karşılaştığım çok iyi iki cevap burada:

1. Manuel test vs manuel test ne zaman
2. Ünite Testi söz konusu olduğunda ne test edilmeyecek?

Genel giderlerin algılanmaması için gerekçeler:

• Şirketiniz için Hemen Zaman / Maliyet Tasarrufu
• Potansiyel Zaman / maliyet tasarrufu, bakım / uzatma / uzatma işlemlerinde uzun vadede siz gittikten sonra bile.

İşinizin kalitesinin kanıtı olarak yanınızdan harika bir ürün bırakmak istemez miydiniz? Bencil terimlerle konuşmak, senin için daha iyi değil mi?

Profesyonel geliştiriciler, birim testleri yazıyor, çünkü uzun vadede zaman kazandırıyorlar. Kodunuzu er ya da geç test edeceksiniz ve kullanıcılarınız bunu yapmazsanız ve hataları daha sonra düzeltmeniz gerekiyorsa düzeltmeleri daha zor olacak ve etkileri daha fazla etkileyebilecekler.

Testleri yapmadan kod yazıyorsanız ve hiç hata yoksa, o zaman sorun yok. Yine de sıfır hata içeren önemsiz bir sistem yazabileceğinizi sanmıyorum, bu yüzden bir şekilde ya da başka bir şekilde test ettiğinizi varsayıyorum.

Birim testleri de eski kodu değiştirdiğinizde veya yeniden düzelttiğinizde gerilemeyi önlemek için çok önemlidir. Onlar yok kanıtlamak için değişim kırmadı eski kod ama size güven çok vermek (bu kadar uzun onlar :) elbette geçerken)

Geri dönüp zaten göndermiş olduğunuz kod için bir sürü test testi yapmam, ancak bir dahaki sefere bir özelliği değiştirmeniz gerektiğinde, bu modül veya sınıf için testler yazmayı denemenizi ve kapsamınızı% 70'e kadar çıkarmanızı öneririm. + herhangi bir değişiklik uygulamadan önce. Bak sana yardım eder mi?

Eğer deneseniz ve dürüst bir şekilde yardımın yeterli olmadığını söylerseniz, o zaman yeterince adil, ancak bence yaklaşımı denerken en azından size değinmesine yardımcı olacak yeterli endüstri kanıtı olduğunu düşünüyorum.

Bu sorunun çoğu TDD yanlısı gibi görünüyor, soru TDD hakkında değil, genel olarak birim testleri hakkında soru sorsa bile.

Birim testinin veya birim testinin yapılmamasının arkasında tamamen nesnel bir kural yoktur. Ancak birçok programcının birim testi yapmadığı anlaşılan birkaç kez var:

1. Özel yöntemler

OOP felsefenize bağlı olarak, karmaşık rutinleri halka açık yöntemlerden ayırmak için özel yöntemler oluşturabilirsiniz. Genel yöntemlerin genellikle birçok farklı yerde çağrılması ve sıklıkla kullanılması amaçlanmıştır ve özel yöntemler çok özel bir şey için yalnızca bir sınıf veya modülde bir veya iki genel yöntem tarafından çağrılır. Genel metotlar için birim testleri yazmak genellikle yeterlidir, ancak sihrin bir kısmını gerçekleştiren temel metotlar değil. Özel bir yöntemde bir şeyler ters giderse, genel yöntem birim testleriniz bu sorunları tespit edebilecek kadar iyi olmalıdır.

2. Zaten bildiğiniz şeyler çalışmalıdır (veya başkası tarafından test edilen şeyler)

Test etmeyi ilk kez öğrenirken birçok yeni programcı buna karşı çıkıyor ve yürütülen her bir satırı test etmeleri gerektiğini düşünüyor. Harici bir kütüphane kullanıyorsanız ve işlevselliği yazarları tarafından iyi bir şekilde test edilmiş ve belgelendirilmişse, birim işlevi testlerinde belirli işlevleri test etmek genellikle anlamsızdır. Örneğin, bir kişi ActiveRecord modelinin, bir davranış için Rails'te zaten iyice test edilmiş olsa bile, ActiveRecord modelinin veritabanına "before_save" geri çağrısı olan bir özniteliğin doğru değerine dayandığından emin olmak için bir test yazabilir. Geri çağırmanın çağırdığı yöntem (ler) belki geri çağırıyor, ancak geri çağırma davranışının kendisini değil. Alınan kütüphanelerle ilgili temel problemler, birim testlerinden ziyade kabul testleriyle daha iyi açıklanacaktır.

İkisi de TDD yapıp yapmadığınızı uygulayabilir.

Ken, ben ve oradaki diğer birçok geliştirici, kariyerlerimiz boyunca birkaç kez sizinle aynı sonuca vardık.

Bulduğunuzu düşündüğüm gerçek (birçokları gibi), uygulamanız için testler yazma ilk yatırımının göz korkutucu görünebilir, ancak iyi yazılmış ve kodunuzun doğru kısımlarına hedeflenmişse, gerçekten bir tondan tasarruf edebilirler. Zamanın

En büyük sorunum mevcut test çerçevelerindeydi. Asla aradığım şeymiş gibi hissetmemiştim, bu yüzden kendi basit çözümümü kullandım. Bu beni gerçekten regresyon testinin "karanlık tarafına" götürmeme yardımcı oldu. Burada yaptığım şeyin temel sözde snippet'ini paylaşacağım ve umarım sizin için işe yarayan bir çözüm bulursunuz.

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

Ondan sonraki en zor kısım, yaptığınız projeye göre hangi ayrıntı düzeyini düşündüğünüzü en iyi "paranın karşılığını almak" olduğunu bulmak.

Bir adres defteri oluşturmak kesinlikle kurumsal bir arama motorundan çok daha az test gerektirecektir, ancak temel hususlar gerçekten değişmiyor.

İyi şanslar!