Ünite test kodunuz “kokuyorsa” gerçekten önemli mi?

Genellikle, birim testlerimi, kopyala ve yapıştır ve diğer tüm kötü uygulamaları kullanarak birleştiririm. Ünite testleri genellikle oldukça çirkin görünüyor, "kod kokusu" dolu, ama bu gerçekten önemli mi? Kendime her zaman "gerçek" kodun "önemli" olduğu sürece önemli olduğunu söylerim. Ayrıca, birim testi genellikle inatçılık işlevleri gibi çeşitli "koklamaktan kesmek" gerektirir.

Kötü tasarlanmış ("koklamak") birim testleri konusunda ne kadar endişelenmeliyim?

Ünite testi kokuları önemli midir? Evet kesinlikle. Bununla birlikte, bunlar kod kokularından farklıdır çünkü ünite testleri farklı bir amaca hizmet eder ve tasarımlarını bilgilendiren farklı bir gerilimler dizisine sahiptir. Koddaki birçok koku testlere uygulanmaz. TDD zihniyetim göz önüne alındığında, birim test kokularının kod kokularından daha önemli olduğunu iddia ediyorum, çünkü kod sadece testleri yerine getirmek için orada.

İşte bazı yaygın birim test kokuları:

• Kırılganlık : Testler önemsiz veya ilgisiz görünen kod değişiklikleri için bile sık ve beklenmedik bir şekilde başarısız mı?
• Devlet Sızıntısı : Testleriniz, örneğin hangi sırayla çalıştırıldıklarına bağlı olarak farklı başarısız mı?
• Kurulum / Teardown Bloat : Kurulum / teardown bloklarınız uzuyor ve uzuyor mu? Herhangi bir tür iş mantığı gerçekleştiriyorlar mı?
• Yavaş Çalışma Zamanı : Testlerinizin çalışması uzun sürüyor mu? Bireysel testlerinizden herhangi birinin çalışması saniyenin onda birinden daha uzun sürüyor mu? (Evet, ben ciddiyim, saniyenin onda biri.)
• Sürtünme : Mevcut testler yeni testler yazmayı zorlaştırıyor mu? Refactoring yaparken kendinizi sık sık test başarısızlıkları ile mücadele ediyor musunuz?

Kokuların önemi, tasarım veya diğer temel hususların, örneğin “dumanın olduğu yerde, ateşin” yararlı göstergeleri olmalarıdır. Sadece test kokuları aramayın, onların altında yatan nedenleri de arayın.

Öte yandan, birim testleri için bazı iyi uygulamalar:

• Hızlı, Odaklı Geribildirim : Testleriniz arızayı hızlı bir şekilde izole etmeli ve size sebebi ile ilgili yararlı bilgiler vermelidir.
• Test Kodu Mesafesini En Aza İndirme: Test ile onu uygulayan kod arasında açık ve kısa bir yol olmalıdır. Uzun mesafeler gereksiz yere uzun geri besleme döngüleri oluşturur.
• Aynı Anda Bir Şey Testi : Birim testleri yalnızca bir şeyi test etmelidir. Başka bir şeyi test etmeniz gerekirse, başka bir test yazın.
• Bir Hata Yazmayı Unuttuğunuz Bir Test : Gelecekte daha iyi ve daha eksiksiz testler yazmak için bu başarısızlıktan ne öğrenebilirsiniz?

Endişelenmek. Kodunuzun beklediğiniz gibi davrandığını kanıtlamak için birim testleri yazıyorsunuz. Güvenle hızlı bir şekilde yeniden yönlendirmene izin veriyorlar. Testleriniz kırılgansa, anlaşılması zorsa veya bakımı zorsa, başarısız testlerden yoksun kalacaksınız veya kod tabanınız geliştikçe testlerden vazgeçerek, ilk olarak test yazmanın yararlarının çoğunu yok edeceksiniz.

Birkaç gün önce Ünite Sanatı Testini okudum . Yazar, üretim kodunuzu yaptığınız kadar, birim testlerinize de dikkat etmeyi savunuyor.

İlk elden kötü yazılmış, sürdürülemez testler yaptım. Bazılarını kendim yazdım. Testin kıçında tutulması gereken bir ağrı olması halinde sürdürülmeyeceği neredeyse garanti edilir. Testler test edilen kodla senkronize edilmediğinde, yalanlar ve aldatma yuvaları haline geldiler. Ünite testlerinin amacı hiçbir şeyi kırmadığımıza güven duymaktır (yani, güven yaratırlar). Eğer testler güvenilir değilse, faydasızlardan da kötüler.

Ünite testiniz aslında "çoğu" durumlarda kodunuzu test ettiği sürece. (En olası bilerek bazen olası tüm sonuçları bulmak zor olduğundan bahseder). Bence "koklamak" kodu sizin kişisel tercihiniz. Her zaman, ıvır zıvır kazıp, ne olduğunu anlamaya çalışmak yerine, onu birkaç saniye içinde okuyabilecek ve anlayabileceğim şekilde kod yazarım. Özellikle de önemli bir süre sonra tekrar geldiğinde.

Alt satır - test, kolay olması gerekiyordu. Kendinizi "koklamak" koduyla karıştırmak istemezsiniz.

Kesinlikle. Bazı insanlar "herhangi bir testin hiç testten daha iyi olmadığını" söylüyor. Kesinlikle katılmıyorum - kötü yazılan testler geliştirme zamanınızı düşürür ve ilk etapta iyi bir birim test olmadıkları için "kırılmış" testler yaparak günlerinizi boşa harcarsınız. Şu anda benim için, testlerimi bir yük yerine değerli kılmak için odaklandığım iki şey:

İdame

Sonucu test etmelisiniz ( ne olur), metodu değil ( nasıl olur). Test için kurulumunuz, uygulamadan mümkün olduğunca ayrılmalıdır: yalnızca kesinlikle gerekli olan servis çağrıları için sonuçları ayarlayın.

• Testlerinizin harici hiçbir şeye bağlı olmadığından emin olmak için alaycı bir çerçeve kullanın
• Favorileri alaylar üzerine taslakları (eğer çerçeveniz birbirinden ayırt ederse)
• Testlerde mantık yok! Ifs, anahtarlar, mobilyalar, kılıflar, try-catch'ler vs. test kodunun içine böcek sokabilecekleri için no-noos'tur.

Okunabilirlik

Testlerinizde, normalde üretim kodunuza izin vermeyeceğiniz testlerden biraz daha fazla tekrarlamaya izin vermek, onları daha okunaklı kılmaksa sorun değil. Sadece bunu yukarıdaki bakım malzemeleriyle dengeleyin. Testin ne yaptığını açıkça belli edin!

• Testleriniz için "düzenleme, hareket etme, iddialı" bir tarz sunmaya çalışın. Bu, senaryonun kurulumunu ve beklentilerini, gerçekleştirilen eylemden ve iddia edilen sonuçtan ayırır.
• Test başına bir mantıksal iddiada bulunun (eğer testinizin adında "ve" varsa, bunu birden fazla teste ayırmanız gerekebilir)

Sonuç olarak, "koklamak" testleri ile çok fazla ilgilenmelisiniz - onlar sadece zamanınızı boşa harcayabilir, değer veremezler.

Sen söyledin:

Birim testi genellikle, taslaklama fonksiyonları gibi çeşitli "koklama korsanları" gerektirir.

Hayatınızı çok daha kolay hale getirmek için Mocking framework kullanmak gibi bazı Unit Test tekniklerini okumakla kesinlikle başa çıkmış gibisiniz. Çok daha fazlasını ve çok daha fazlasını içeren “Birim Test Sanatı” nı şiddetle tavsiye ederim . Kötü yazılmış, sürdürülemez, "koklamak" testleriyle uzun süre mücadele ettikten sonra aydınlatıcı buldum. Bu yıl yaptığım en iyi zaman yatırımlarından biri!

Sizin için iki soru:

• Test ettiğinizi düşündüğünüz şeyi test ettiğinize kesinlikle emin misiniz ?
• Başkası ünitesi testi bakar, bunlar kod olduğunu anlamaya mümkün olacak yapmak gerekiyordu ?

Ünite testlerinizde, en çok kurulum ve parçalama kodu olan tekrarlayan görevlerle baş etmenin yolları vardır. Temel olarak, bir test kurma yöntemine ve bir test yırtma yöntemine sahipsiniz - tüm birim test çerçevelerinin bunu desteklemesi.

Ünite testleri küçük ve kolay anlaşılmalıdır. Olmazlarsa ve test başarısız olursa, sorunu oldukça kısa bir sürede nasıl çözeceksiniz? Koda geri dönmeniz gerektiğinde, yolda birkaç ay kendiniz için kolaylaşın.

Çöp kokmaya başladığında, dışarı çıkarmanın zamanı gelmiştir. Test kodunuz, üretim kodunuz kadar temiz olmalıdır. Annene gösterir misin?

Burada diğer cevaplara ek olarak.

Ünite testlerinde düşük kalite kodu ünite test grubunuzla sınırlı değildir.

Ünite Testi tarafından doldurulan rollerden biri Dokümantasyondur.

Birim Test paketi, bir API'nin nasıl kullanılması amaçlandığını bulmak için arayan yerlerden biridir.

API'nizin arayanlarının birim test paketinizin parçalarını kopyalaması olası değildir, bu da kötü test paketi kodunuzun başka bir yerde canlı kodu etkilemesine neden olmaz.

Neredeyse bir cevap vermedim, çünkü meşru bir soru olarak buna nasıl yaklaşılacağına karar vermem uzun zaman aldı.

Programcıların "en iyi uygulamalara" dahil olma nedenleri estetik nedenlerden değildir veya "mükemmel" kod istediklerindendir. Çünkü onlara zaman kazandırır.

• Zaman kazandırır çünkü iyi kodun okunması ve anlaşılması kolaydır.
• Zaman kazandırır çünkü bir hatayı düzeltmeniz gerektiğinde bulunması daha kolay ve daha hızlı olur.
• Zaman kazandırır, çünkü kodu genişletmek istediğinizde bunu yapmak daha kolay ve hızlıdır.

Öyleyse, sorduğunuz soru (benim açımdan) kendimi zaman kazanmalı mı yoksa zamanımı boşa harcayacak bir kod yazmalı mıyım?

Bu soruya yalnızca zamanın ne kadar önemli olduğunu söyleyebilirim.

Bilginize: inat, alay ve maymun yama tüm meşru kullanımları vardır. Sadece kullanımları uygun olmadığında “kokar”.

Özellikle birim testlerimi çok fazla hatalı yapmak istemem. Sağlam olma adına hata işlemeye başlayan birim testlerini gördüm. Sonunla, yakalamaya çalıştıkları böcekleri yutan testler. Ünite testleri ayrıca bazı şeylerin işe yaraması için sık sık bazı ilginç şeyler yapmak zorundadır. Yansımayı kullanan özel erişimciler hakkındaki tüm fikrinizi düşünün ... eğer üretim kodunun her yerinde bir demetini görürsem, 10 üzerinden 9 kez endişelenirdim. Ne test edildiğini düşünmek için daha fazla zaman harcanması gerektiğini düşünüyorum. kod temizliği yerine. Herhangi bir önemli yeniden düzenleme işlemi yaparsanız, testlerin yine de sık sık değiştirilmesi gerekir, peki neden onları bir kenara kesmek, biraz daha az sahiplik duygularına sahip olmak ve zamanı geldiğinde yeniden yazmak veya yeniden düzenlemek için daha fazla motive olmalısınız?

Ağır, düşük seviyeli kapsama için gidiyorsanız, ciddi değişiklikler yaparken test kodunda ürün kodunda olduğu kadar çok veya daha fazla zaman geçireceksiniz.

Test kurulumunun karmaşıklığına bağlı olarak kod daha karmaşık olabilir. (httpcontext.current - örneğin, doğru bir şekilde yanlış bir tane kurmaya çalışmanın korkunç canavarı)

Ürününüz, mevcut arayüzlerde nadiren değişiklik yaptığınız bir şey değilse ve birim seviyesindeki girişlerinizi ayarlamak çok basittir, testlerin gerçek ürün olarak anlaşılmasından endişe duyan LEAST'de olacağım.

Kod Kokuları, kodun yalnızca zaman içinde bir noktada değiştirilmesi veya anlaşılması gereken bir konudur.

Bu yüzden verilen ünite testine "yaklaşmak" gerektiğinde kod kokularını düzeltmelisiniz, ama daha önce değil.