Birim testleri için yeni bir ad [kapalı]

Ünite testinden hiç hoşlanmadım. Her zaman yapmam gereken iş miktarını artırdığını düşünürdüm.
Görünüşe göre, bu sadece yazdığınız gerçek kod satırı sayısı açısından doğrudur ve ayrıca, testler ve test odaklı geliştirme ile bir saat içinde yazabileceğiniz faydalı kod satırlarının sayısındaki artışla tamamen dengelenmiştir.

Şimdi sık sık ilk kez işe yarar, yararlı kod yazmak için izin gibi birim testleri seviyorum! (Ahşap üzerine vurmak)

İnsanların, sıkı zaman çizgileri altında veya başkalarının yapmadığı bir ortamda, birim testleri yapmaya veya test odaklı geliştirme ile bir projeye başlama konusunda isteksiz olduklarını gördüm. Tür, denemek için kültürel bir ret bile.

Ünite testi ile ilgili en güçlü şeylerden birinin, yeniden düzenleme yapmanıza verdiği güven. Aynı zamanda yeni bulunan bir umut verir, kodumu yeniden düzenlemek / iyileştirmek için başka birine verebilirim ve birim testlerim hala çalışıyorsa, kütüphanenin değiştirdikleri yeni sürümünü korkusuzca kullanabilirim.

Birim testinin bu son yönü yeni bir isme ihtiyaç duyduğunu düşünüyorum. Birim testi, bu kodun şimdi ve gelecekte ne yapması gerektiğine dair bir sözleşme gibidir.
Kelime testini duyduğumda, bir bileşiğin etkinliğini görmek için üzerinde birden fazla deney yapılmış olan fareler kafeslerde düşünüyorum. Birim testi bu değildir, en etkili yaklaşımın ne olduğunu görmek için farklı kodlar denemiyoruz, hangi girdilerden hangi çıktılardan beklediğimizi tanımlıyoruz. Fare örneğinde, birim testleri, farelerde yapılan deneylerin aksine, evrenin nasıl çalışacağının tanımlarına benzemektedir.

Çatlakta mıyım yoksa test yapmayı reddeden başka biri var mı ve bunu yapmak istemediklerine benzer bir neden mi düşünüyorlar?
Siz / başkaları test etmemek için hangi nedenleri veriyorsunuz?
Ünite testinde motivasyonlarının ne olduğunu düşünüyorsunuz?

Ve itirazların bir kısmını aşabilecek birim testleri için yeni bir isim olarak jContract'a ne dersiniz? (Biraz Java merkezli biliyorum :) veya Birim Sözleşmeleri?

Çatlakta mıyım yoksa test yapmayı reddeden başka biri var mı ve bunu yapmak istemediklerine benzer bir neden mi düşünüyorlar?

Birim testindeki kelime testi, insanların bunun entegrasyon testi veya kullanıcı arayüzü testi olduğunu düşünmesini sağlar, çünkü bu şimdiye kadar yaptıkları tek testtir. Java'yı javascript'e koymak gibi.

Bir şey kötü bir isme sahip olduğunda ve insanların bunun hakkında düşünmesini etkilediğinde buna çerçeveleme hatası denir. Çerçeveleme hataları yüzeysel olma eğilimindedir - insanlar akıllıdır ve her türlü kötü ismi, kötü metaforları görebilirler.

Siz / başkaları test etmemek için hangi nedenleri veriyorsunuz?

Sahte / sahte /

Ünite testinde motivasyonlarının ne olduğunu düşünüyorsunuz?

Birim testi mütevazı bir kavram sayısına sahiptir ve kötü birim testleri yazmayı bırakmadan ve iyilerini yazmaya başlamadan önce önemsiz olmayan bir iş yapılması gerekir. İnsanlar birim testin ne olduğunu açıklama konusunda iyileştikçe, evlat edinme artacaktır. Deneyimlerime göre, birim testinin üretkenlik ve kod kalitesi üzerinde neredeyse büyülü bir etkisi var. Ancak bu şekilde başlamadı. Başlangıçta birim test çerçevelerini entegrasyon testleri yazmanın uygun bir yolu olarak kullandım.

İsim değişikliği kavramı çoktan keşfedildi. Buna Davranış Odaklı Kalkınma denir . Bunu ortaya çıkaran çocuklar, aynı argümanların çoğunu ve henüz yaratılmamış bir şeyi test etmek için doğal olmayan uyumu fark ettiler. Bunun yerine, kavramları yürütülebilir bir şartname yazmaktır (TDD'nin aslında neyle ilgili olduğu).

Aynı geri dönüşü fark ettim. Ayrıca bir çok insanın birim testleri nasıl yazacağını bilmediğini fark ettim. Bilimsel süreç disiplinlerinde eksikler ve sadece birim test çerçevesini her şeyi birbirine bağlamanın ve hata ayıklayıcıyı başlatmanın bir yolu olarak kullanıyorlar. Kısacası, zamanlarının kullanımını gerçekten geliştirmiyorlar. Size bir tane iddia beyanı değil, onlarca satır uzunluğunda (30+ satır) kaç tane birim test gördüğümü söyleyemem. Bunu gördüğümde, geliştiriciyle çalışmanın ve onlara bir iddianın ne olduğunu ve gerçekten test eden birim testlerinin nasıl yazıldığını öğretmenin zamanının geldiğini biliyorum.

Buradaki sözleşmelere çoğu durumda "arayüz" denir. Birim testlerine sahip olmak, testleri de değiştirebileceğiniz için sözleşmeleri kendiliğinden garanti etmez, bu yüzden sadece kütüphane test edildiğinden kütüphanenin yeni sürümünü kullanabileceğinizi bilmiyorsunuzdur. Kütüphaneyi kullanan kodu da test etmeniz gerekir. Bu, diğer birim testlerinden farklı değil, bu yüzden neden yeni bir isme ihtiyaç duyulacağını anlamıyorum.

Sanırım, sizin gibi, çoğu insan bunu yapmak için isteksizdir çünkü daha fazla iş olduğunu ve işe yaramadığını düşünüyorlar.

TDD'yi neden sevmediğimi anlatacağım: Bu, içindeki değeri göremediğim veya her modifikasyondan sonra tüm kodumu doğrulamak için çalıştırabileceğim bir test paketinin avantajlarını tanımadığım için değil.

Çünkü buna ihtiyacım yok. Oldukça eski bir okul geliştiriciyim, bir delikanlı olduğumda, düzenleme yazmaya devam eden süslü entegre hata ayıklayıcılarımız yoktu ve bir derleme oldukça uzun zaman alabilirdi, bu yüzden bir şeyler almak zorunda kaldık doğru, en baştan. Böyle bir eğitim verildiğinde, bir sürü birim test yazmanın beni daha verimli veya kodumu daha hatasız hale getireceğini gerçekten görmüyorum.

Kodumu test ediyorum, ama her zaman yaptığım gibi, bu tek tek parçalar yerine her şey üzerinde. Belki de 'birim testlerim' var, ama bunlar daha kaba taneli.

Benim nedenim bu. Bunu yapma ihtiyacımı göremiyorum. Ürettiğim kod yeterince iyi ve durum buysa, neden kırık olmayan bir şeyi düzeltmek için süreçlerimi değiştirmeliyim?