Birim testlerinde Kod Kalitesi?

Ünite testleri yazarken, kodun iyi kalitede ve okunabilir olmasını sağlamak için fazladan zaman harcamakta fayda var mı?

Test yazarken , daha hızlı yazmak ve çok fazla değişken kullanmaktan kaçınmak için genellikle Demeter Yasasını çiğniyorum . Teknik olarak, birim testleri doğrudan yeniden kullanılmaz - kesinlikle koda bağlıdırlar, bu yüzden üzerlerinde çok fazla zaman harcamak için herhangi bir neden görmüyorum; sadece işlevsel olmaları gerekir.

Ünite testlerinize kalite ve okunabilirlik açısından üretim kodunuzdan daha iyi bakmıyorsanız kesinlikle aynı şeyi yapmalısınız. Birim testler genellikle bazı kod parçalarının ne yaptığını kavramaya çalışırken ilk bakacağınız şeydir ve okuyucunun sınava bakarken ne risk altında olduğunu çabucak anlaması gerekir. Birim testleri de çok fazla değişme eğilimindedir ve eğer tasarımları sağlam değilse çok kırılır, bu da testlerin faydalarını geçersiz kılar.

Demeter Yasası'nın ihlali kesinlikle ünitenizde aklıma gelen diğer 2 kişinin yanı sıra bu testlerden dolayı bir problemdir:

• Testleriniz, Düzenleme veya Yasa bölümlerinde Demeter Yasasını ihlal ederse, ünite testleriniz sadece sizin kodunuzun bir başka tüketicisi olduğundan ve muhtemelen aynı zamanda test edilen sınıfı arayacak ve çalıştıracağınız için üretim kodunuzun da bir işareti olabilir. başka bir üretim kodunun yapacağı şekilde.

• Eğer testleriniz Demeter Yasasını Assert bölümlerinde ihlal ederse (yani, test edilen nesnenin bağımlılık grafiğine derinlemesine yerleştirilmiş bir şeyin değerini doğrularsanız), bunlar testlerden ziyade entegrasyon testleridir. Başka bir deyişle, TestA’da ABCD’nin bir şeye eşit olduğunu iddia ederseniz, aslında sadece A’dan ziyade D ve A’yı test etmeye çalışıyor olabilirsiniz .

Bu arada, söylediğinde

Daha hızlı yazmak ve çok fazla değişken kullanmamak için Demeter Yasasını çok sık çiğniyorum.

bu yazının farkında olmalısın

var grab = myDependency.Grab;
var something = grab.Something;
var very = something.Very;

very.Deep();

aslında Demeter'den daha iyi değil Demeter

myDependency.Grab.Something.Very.Deep();

Eğer demek istediğin buysa.

Ünite testleri için iyi kalitede kod yazmak kesinlikle zaman harcamakta fayda var:

• Diğer tüm kodlar gibi bakım gerektireceklerdir.
• Birim testleri, sisteminiz için en iyi dokümantasyon kaynaklarından biridir ve tartışmasız en güvenilir formdur. Gerçekten göstermeliler:
  • Amaç: "beklenen davranış nedir?".
  • Kullanım: "Bu API'yı nasıl kullanmalıyım?".
• Başka herhangi bir kod gibi hata ayıklama gerektireceklerdir.

Biraz daha geçici bir yaklaşımın lehine olan bir faktör, birim testlerinizin hiçbir zaman halka açık bir API olamayacağıdır, bu nedenle hangi arayüzler / vb. Hakkında endişelenmenize gerek yoktur. Maruz kalıyorsun.

Evet, önemli. Birim testlerinin diğer kodlarla karşılaştırılabilir bir standartta yapılmasının birkaç nedeni vardır:

• Her birim testi aynı zamanda testiyen için bir belge görevi görür. Testler kapsamlı olduğunda ve olabildiğince fazla uç durumu ve hata koşullarını kapsadığında, genellikle bir sınıf veya işlevin yorum belgelerini değiştirebilirler. Ayrıca, kod bazında yeni olan insanlar için bir başlangıç ​​noktası olabilir.

• Birim testleri de buggy olabilir. Kod iyi yazılmışsa ve hatalar daha belirgindir.

• Herhangi bir nedenle, daha sonra bir modülü bölmeniz gerekiyorsa, muhtemelen birim sınamalarını da bölmeniz gerekir. Testler kolayca farkedilebilir bağımlılıklara sahip olacak şekilde yazılırsa, bu daha kolaydır.

Bu her zaman pratiklik meselesi olduğunu söyledi. Kodunuzun diline ve niteliğine bağlı olarak, testlere test etmeleri gereken koddan çok daha fazla zaman harcamadan "temiz" ünite testleri yazmak zor olabilir. Bu durumda, genellikle tam kapsamlı kapsama konusunda çok fazla endişelenmeden, kolay, hızlı işleri ve en kritik işlevleri test etmeye geri dönüyorum. Ne zaman bir böcek daha sonra ortaya çıkarsa, bunun için bir test yazarım ve onları daha iyi hale getirmek için yeni testi ve var olanları yeniden değerlendirebilir miyim kontrol ederim.

en içindekileri okuyamazsanız ve bir daha başarısız olduğunda ne test ettiğini öğrenemezseniz, bir kez daha hata ayıklama süresini harcayacaksınız (bir kez testin ne olduğunu öğrenmek için ve bir kez test ettiği kodu düzeltmek için)

dürüst olmak gerekirse, en düşkünlerin beklenen bir sonucu olmalı; prosedürü yapın; fiili sonuç almak; yazılması ve anlaşılması kolay olan yapıya göre test yapılması bekleniyor

Test kodu, üretim kodunuz kadar sevgi almalıdır. Okunabilirlik için, belki daha da fazla. Sizden başkasının (kodu bıraktıktan iki hafta sonra da dahil olmak üzere) ne olup bittiğini anlaması gerekiyorsa, kodunuzu net bir şekilde güzelleştirmelisiniz.

Bunun anlamı:

• Test verilerinin oluşturulmasını üretici sınıflarına çıkarın.
• Çok değişkenli iddiaları ayrı iddia yöntemlerine çıkarın.
• Adlandırma konusunda çok kesin olun. Assert.That(x4, Is.EqualTo(y16*2*SOME_VALUE), ASS_ERR_TXT_56)Çoğu okuyucuya çok az dikkat gösterir.

Aşırı ele alındığında testler yazılabilir, böylece neredeyse okunması kolay ve nesir olarak anlamak kolaylaşır. Aşırı test cihazı, muhtemelen 10 çizgiden uzun bir birim testinin kötü olduğunu söylüyor.

En önemli pratik sebep, kodu her değiştirdiğinizde birim testlerini değiştirmenizdir. TDD yapıyorsanız, önce birim testlerini bile değiştiriyorsunuz.

Bunlardan herhangi birini testlerinizde yapın:

• Yinelenen kod
• Okunabilirliği azaltmak
• Sıkı bağlama
• Zamansal kaplin
• Yüksek siklomatik karmaşıklık (çok fazla bağımlılık)

Ve bir değişiklik gerektiğinde çok fazla iş yapıyorsunuz.

Testlerine önerdiğin gibi davran ve pişman olacaksın. Muhtemelen "TDD'nin işe yaramadığı" yanlış sonucuna bile varacaksınız.

Bu birim testlerinin "geçici" olup olmamasına bağlıdır. Eğer

1. Test sıklıkla kullanılacaktır;

2. Geliştiriciler, diğer geliştiriciler tarafından yazılmış birim testleri ile çalışmak zorundadır;

3. Testlerin çoğu birim testleriyle yapılır.

o zaman testler uygun şekilde yazılmalıdır. Testin kendisinde bir hata olması durumunda, özellikle testin yazılmasından bu yana bir süre geçtiyse, hatayı bulmak ve düzeltmek zor olacaktır.

Öte yandan, bu testler yalnızca geliştiriciler tarafından yalnızca kendileri tarafından kullanılıyorsa, sorun değil. Ancak yine de 'okunabilir' kod yazmak daha tercih edilir. Cırcır ucubesinin dediği gibi, testlerinizi düzeltmek için doğru bir şekilde yazmak için harcadığınızdan daha fazla zaman harcayacaksınız.