Profesyonel bir geliştirici olarak, birim testleri yazmamak kabul edilebilir mi? [kapalı]

Sadece TDD / otomatik birim testinin artılarını ve eksilerini merak ediyor ve toplumun profesyonel geliştiricilerin birim testlerini desteklemeden uygulama yazmasının kabul edilebilir olup olmadığı konusundaki görüşlerini mi arıyorsunuz?

Neyi test etmek için?

% 100 kod kapsamından bahsediyorsanız, son derece nadirdir, kullanışlı değildir ve çoğu zaman imkansızdır. Aynı şekilde, CRUD ile ilgili kodu test etmek zaman kaybıdır ve gerçekten yararlı bir şey yapmak yerine ihtiyacınız olmayan kodu yazarak saatlerce harcamak profesyonelce olmazdı .

Şimdi, bir geliştirici olarak, birim testlerini nasıl yazacağınızı ve bunlara nerede ihtiyacınız olduğunu bilmelisiniz.

teori

Birim testlerinin "birimleri" test etmek için yaygın bir yanlış kanı vardır .
Birim testleri, diğer tüm testler, test işlevselliği . Test edilebilecek başka bir şey yok.

Bununla birlikte, karmaşık bir sistemin işlevselliği genellikle etkili bir şekilde test edilemez.
Diyelim ki bir kullanıcı "Sil" düğmesine basar ve hiçbir şey olmaz. Neden? Veritabanında bir hata olabilir, bir bağlantı kopabilir, bir çekirdek mantık arızalanabilir veya bir işlem bile başarılı olabilir, ancak arabirim düzgün şekilde güncellenmedi. Her katman, birbirini çağıran birçok işlev içerebilir ve hatanın nerede olduğu her zaman net değildir.
Birim testleri, bileşenlerin ayrılması ve ayrı ayrı test edilmesi paradigmasına dayanır .

Bir kez daha, tüm sistemin çalışacağını garanti etmez, ancak testi basitleştirir.

TDD tek başına bir gereklilik değildir. Önce bir geliştiriciyi "aslında ne kodlayacağım?" Diye yanıtlamaya zorlayarak kodlamayı basitleştirir.

Maliyetler

Birçoğu test yazmamakla zaman kazandıklarını düşünüyor. Yanlış. Stratejik düşünerek , bir hatanın maliyeti, ortaya çıkmadan tespit edilmeye kadar geçen süre ile katlanarak artar .

Kodunuzda bir hata yaptığınızı ve aynı gün tespit edip düzelttiğinizi varsayalım. Maliyet X $ .
Hatanın tespit edilmediğini ve haftalık dahili yapıya gittiğini varsayalım. Neyse ki, QA bunu tespit etti, böcek izleyicide bir hata yarattı, sorun 5 kişilik bir toplantıda 5 dakikalık bir tartışma konusuydu. Son olarak, düzeltin. Maliyet, herkes tarafından harcanan işgücünün toplamıdır ve bu durumda 3 $ * X olabilir .
Hata beta testine gidip daha fazla kişiyi içeriyorsa ne olur? Diyelim diyelim ki, 10 $ * X .
Uzun süre fark edilmeden kalırsa, 1000 müşteriye gitti (umarım bir milyona değil!), 10 tanesi bunu tespit etti, destek personelinizle bir tartışma başlattılar, bazıları patronunuzu arayabilir, takım arkadaşlarınız onu yeniden üretmeye çalışır Sonunda, hata size geri gelir ve düzeltirsiniz. Toplamda ne kadar? Eh fazla 50 $ * X .

Gördüğünüz gibi, bir hata er ya da geç size (ya da iş arkadaşınıza) geri döner . Tek fark, ne zaman gerçekleştiği ve ne kadar tutacağıdır.
Birim testleri hataların ömrünü kısaltır ve dolayısıyla maliyetleri azaltır.

Pro'nun

• Birim testleri geliştiricinin daha iyi kodlamasını sağlar . Kadar basit.
• Size zaman kazandırır;
• Maliyetleri düşürürler;
• Birim testleri, test ettikleri kodla birlikte yaşar. Herhangi bir değişiklik talebi üzerine (her zaman olur), testler uyarlanacaktır.

Eksileri

Test yazmamak için tek bir mazeret görüyorum. Bir prototip yazıyorsanız, örneğin asla diğer insanlara gitmeyecek bir şey. Ya da belki tek bir kullanım için bir şeyler yazıyorsunuzdur.

Tabii, bu değil yazma küçük iç yardımcı programları için birim testler veya test araçları veya iş gerçekten senaryolara kabul edilebilir gerçekten kaliteli dışındaki şeye ihtiyacı ve yazılım yapmış ve kısa sürede sadece çalışan olsun ki profesyonel geliştirici find olarak sizin olmadan.

Deneyimlerime göre, birim testleri tarafından yakalanabilecek hataların% 95'i, özellikle veritabanı tasarımı değiştikten sonra veri katmanına yapılan çağrılardan gelir. Bir veritabanı kullanıyorsanız, erişmek için kullandığınız her yöntemin üzerinde bir test yapın. Testlerin ayrıntılı olması bile gerekmez, sadece akıl sağlığı kontrolleri.

Sorunuza cevap olarak - bir veritabanına erişiyorsanız ve profesyonel bir geliştiriciyseniz, birim testlerini kullanmanız gerekir. Aksi takdirde, duruma göre değişir.

Bu gerçekten uygulamanın nasıl kullanılacağına bağlıdır. Bu kritik bir uygulama mı? Yoksa sadece geliştiriciler tarafından dahili olarak kullanılan basit bir doğrulama uygulaması mıdır? Şirketiniz için temel uygulamalar üzerinde çalışırken, iş kararlarının karşılandığından emin olmak için gereken birim testleri yapılmalıdır. Şirketinize bağlı olarak, müşterilerin gördüğü uygulamalar ve hataların maliyeti olabilir. İyi yapıldığında, birim testleri, uygulamalarınızın dağıtıldığında çalışmasını sağlamak için büyük bir yardımcı olabilir. Ancak bu bir tedavi değildir ve insan testleri hala yapılmalıdır. Basit dahili (veya yardımcı) uygulamalar için birim testlerine gerek yoktur, ancak yine de iyi yazılmalıdır.

TDD sadece ilk önce sınav yazma ile ilgili değildir. Bu, kodunuzun kolayca test edilebilir olduğundan emin olmakla ilgilidir. Ve çoğu zaman kolayca test edilemeyen kodların okunması / hata ayıklanması / bakımı daha kolaydır. Kolayca test edilemeyen kodlardan çoğu, SOLID gibi kalıpları ve OO ilkelerini de takip eder. Profesyonel bir geliştirici olarak kodunuzun her zaman bu şekilde yazılması gerektiğini savunuyorum.

Kesinlikle "test yok" istemiyorsunuz. Birim testleri yazarsanız, en azından kodunuzun testlerinizle eşleştiğinden emin olabilirsiniz (ancak testlerinizin belirtimlerinize uygun olduğundan emin olmanız gerekir).

Yine de sahip olduğunuz tek şey birim testleri ise yapılmaz. Muhtemelen hala entegrasyon testleri ve uçtan uca testler yapmanız gerekir (ve zaman içinde hata regresyonlarını yakalamak için test senaryoları biriktirir).

Burada bir uzuv çıkacağım ve bunun çoğunlukla öznel olduğunu ve hedeflerinize bağlı olduğunu söyleyeceğim. tl; dnr: Yapmak güzel, ama bu konuda dogmatik olmak sadece daha fazla soruna yol açacak.

TDD / Birim testleri kodunuzun kararlılığını artıracaktır. Kod tabanını gerçekten iyi bilmeden değişiklik yapmayı kolaylaştırıyorlar, daha hızlı bir şekilde yeniden düzenlemenize izin veriyorlar, aptalca bir şey yapmadığınızdan emin olmanızı sağlıyorlar. Birim testleri de zaman kaybı olabilir. Kod yazmak için harcanabilecek zaman. Ayrıca, körü körüne takip ederseniz kodunuzun işe yaramadığını düşünmenize kandırmanıza da izin verebilir.

En iyi uygulamaları destekleyen ve bunları uygulamak için size zaman veren bir şirket için çalışıyorsanız ve sürecek bir uygulama istiyorsanız, herkes için birim testleri ve kod incelemelerini kullanmak ve uygulamak en iyisidir. Bir QA ekibine sahip olmak, geliştiriciler kötüye kullanmazsa kabul edilebilir bir yedek olabilir. Bir prototip (hatta üretim prodüksiyonu) yazıyorsanız, duman testleri yapmak daha hızlı olabilir.

Eğer bir karmaşa dünyanın sonu olmayacak bir şey üzerinde çalışıyorsanız, muhtemelen daha az kapsama alanı iyidir. Finansal işlemler? Çok. Kod tabanını bilen güçlü geliştiricilerden oluşan bir ekibiniz varsa, birlikte iyi çalışın ve ciro yok, muhtemelen daha az kapsama alanına ihtiyacınız var. Vb.

Yani muhtemelen bir işlevi olacak

• Takım büyüklüğü / cirosu
• Uygulamanın istenen raf ömrü
• Uygulama ve kritik arızaların ne olduğu
• Geliştirme programına göre en iyi uygulamaların uygulanması için sağlanan süre
• Takım yeteneği (bu, iyi bir programcı olmanız anlamına gelmez, birim testleri yazmamanız gerektiği anlamına gelir, ancak genç geliştiricileri olmayan bir takım, pantolonun koltuğunda daha başarılı bir şekilde uçabilir)

Birim testleri yazmanın kabul edilemeyeceği birçok durum vardır. TDD şu anda 'içeride', ancak gümüş bir kurşun değil.

Size zaman ve gözyaşı kazandıracak Sürdürülebilir Birim Testleri yazmak profesyoneldir !

Bir var misconception that Unit test finds bugs. Peki bu tüm durumlar için geçerli DEĞİLDİR. Birim testi, hataları bulmak veya regresyonları tespit etmekle ilgili değildir. Tanımı gereği examine each unit of your code separately,. Ancak uygulamanız gerçekte çalıştığında, tüm bu birimlerin birlikte çalışması gerekir ve hepsi bağımsız olarak test edilmiş parçalarının toplamından daha karmaşık ve incedir.

Bu nedenle, Birim testinin amacı (TDD süreci içinde) yazılım bileşenlerinin sağlam bir şekilde tasarlanmasıdır.

Düzenleme: Birim sınamaların hataları gerçekten algıladığı bir istisna vardır . Birimin kodunu yeniden düzenlediğinizde veya yeniden yapılandırdığınızda, ancak davranışını değiştirmenin bir anlamı yoktur. Bu durumda, birim testleri genellikle birimin davranışının değişip değişmediğini size söyleyebilir.

Profesyonel bir geliştirici olarak, birim testleri yazmamak kabul edilebilir mi?

Hayır.

Şüphesiz - Bu, bir taze öğrenmenin ilk derslerinden biri olmalıdır. Sen gerekir kodunuzu çalıştığını kanıtlamak için birim testleri geliştirmek önce size kod test için hazır olduğunu QA söyle. Bunu yapmamak proje maliyetlerini ve takım moralini düşürür.

Bu birim testleri ne kadar kapsamlı olmalıdır?

İşte turnusol testi: Eğer KG kodunuzda bir hata bulursa, patronunuza gösterdiğiniz özeni göstermek için birim test (ler) inizi kullanmakta rahat olacak mısınız?

Cevabınız 'Hayır' ise, daha iyi bir birim testi (veya testleri) yapmalısınız.
Cevabınız 'Evet' ise, kodunuz doğrulama için hazırdır.

Profesyonel bir geliştirici olarak, otomatik birim testleri yazmamak kabul edilebilir mi?

Evet.

Özellikle otomatik ünite testleri yazmak için harcanan zaman ve çaba, testten kazanılan faydadan daha ağır basarsa. Bu, alay edilmesi zor olabilecek UI kodunu içerir, ancak bunlarla sınırlı değildir.

Vurgu: Ben değilim değil o UI kodu için otomatikleştirilmiş birim testleri yazmak için imkansız olduğunu söyledi. Sadece deneyimlerime göre, bazı UI kodları için otomatik birim testleri yazmanın bazen zor olduğunu söylüyorum .