Bunu düşün:

public function polynominal($a, $b, $c, $d)
{
    return  $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d;
}

Yukarıdaki işlev için çeşitli testler yazdığınızı ve kendinize ve başkalarına "işe yaradığını" kanıtladığınızı varsayalım.

Neden bu testleri kaldırmıyor ve sonsuza dek mutlu yaşıyorsunuz? Benim düşüncem, bazı fonksiyonların işe yaradıkları kanıtlandıktan sonra sürekli test edilmelerine gerek olmadığıdır. Bunu ifade eden karşı noktaları arıyorum, evet, bu işlevlerin hala test edilmesi gerekiyor, çünkü: ... Ya da evet, bunların test edilmesi gerekmez ...

Gerileme testi

Her şey regresyon testi ile ilgili .

Bir sonraki geliştiricinin yönteminize baktığını ve sihirli sayılar kullandığınızı fark ettiğinizi hayal edin. Büyülü sayıların kötü olduğu söylendi, bu yüzden iki sabit yarattı, biri iki numara, diğeri üç numara için - bu değişikliği yaparken yanlış bir şey yok; Zaten doğru uygulamanızı değiştirdiği gibi değildi.

Dikkatin dağıldığından iki sabiti tersine çevirir.

Kodu onaylıyor ve her şey yolunda görünüyor, çünkü her işlemden sonra çalışan herhangi bir regresyon testi yok.

Bir gün (haftalar sonra olabilir), başka bir yerde bir şeyler kırılıyor. Ve başka bir yerde, kod tabanının tamamen zıt olduğu yerde, yani polynominalişlevle ilgisi yok gibi görünüyor . Saatlerce acı veren hata ayıklama suçluya yol açıyor. Bu süre zarfında, uygulama üretimde başarısız olmaya devam eder ve müşterilerinize birçok soruna neden olur.

Yazdığınız orijinal testlerin tutulması böyle bir acıyı önleyebilir. Dikkat dağıtıcı geliştirici kodu kabul eder ve neredeyse anında bir şeyleri kırdığını görür; bu kod üretime bile ulaşmaz. Birim testleri ayrıca hatanın yeri hakkında da çok kesin olacaktır . Bunu çözmek zor olmazdı.

Yan etki...

Aslında, çoğu refactoring, büyük ölçüde regresyon testine dayanmaktadır. Küçük bir değişiklik yapın. Ölçek. Geçerse, her şey yolunda.

Yan etki, eğer testler yapmazsanız, pratik olarak herhangi bir yeniden düzenleme işleminin kodu çiğneme riski büyük olması. Bu birçok durum göz önüne alındığında, yeniden yapılanmanın yapılması gerektiğini yönetime anlatmak zaten zor , önceki yeniden yapılanma denemelerinizde birden fazla hata ortaya çıktıktan sonra bunu yapmak daha da zor olacaktır.

Eksiksiz bir test grubuyla, yeniden düzenlemeyi ve çok daha iyi, daha temiz kodları teşvik ediyorsunuz. Risksiz, düzenli olarak daha fazla refaktör için çok cazip hale gelir.

Gereksinimlerdeki değişiklikler

Diğer bir önemli özellik ise gereksinimlerin değişmesidir. Sizden karmaşık sayıları kullanmanız istenebilir ve aniden, önceki testleri bulmak, geri yüklemek ve yeni testler eklemeye başlamak için sürüm kontrol günlüğünüzü aramanız gerekir.

Neden bütün bu güçlük? Neden daha sonra eklemek için testleri kaldırmak? Onları ilk etapta tutabilirdin.

Çünkü hiçbir şey böcek olamayacak kadar basittir.

Kodunuz, bunun yüzünde iken hatasız görünüyor. Aslında, bir polinom fonksiyonunun basit bir programatik temsilidir.

Bir hata olması dışında ...

public function polynominal($a, $b, $c, $d)
{
    return  $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d;
}

$xkodunuza giriş olarak tanımlanmaz ve dile veya çalışma zamanına veya kapsam belirlemeye bağlı olarak, işleviniz çalışmayabilir, geçersiz sonuçlara neden olabilir veya bir uzay gemisiyle çakışabilir .

Zeyilname:

Kod hatalarınızı şimdilik ücretsiz olarak düşünebilirsiniz, ancak bu durumun ne kadar sürdüğünü söylemek zor. Bu kadar önemsiz bir kod parçası için bir test yazmanın buna değmeyeceği söylenebilir olsa da, testi zaten yazmış olması işin yapılmasının ve silinmesinin somut bir güvenlik görevlisini silmesinin yolunu açıyor.

Ek not, bir test paketinin sağladığı kapsamın iyi bir göstergesi olan kod kapsamı hizmetleridir (coveralls.io gibi). Her kod satırını kaplayarak, yaptığınız testin miktarını (kalitesi değilse) iyi bir ölçüt verirsiniz. Nerede küçük testlerin bir sürü birlikte, en azından bu hizmetler size değil o olur bir hata aramaya.

Sonuçta, zaten yazılı bir sınavınız varsa, devam edin . Çünkü onu silmekten alan veya zamandan tasarruf, eğer bir hata meydana gelirse, muhtemelen teknik borçtan çok daha az olacaktır.

Evet. Kesin olarak% 100 güvenle söyleyebilseydik: bu işlev asla düzenlenmez ve asla başarısız olmasına neden olabilecek bir bağlamda çalışmayacak - eğer söylersek, testleri düşürebilir ve her milisaniyeden bir kaç milisaniye kurtarabiliriz. CI yapı.

Ama yapamayız. Veya birçok fonksiyonla yapamayız. Tam olarak hangi güven eşiğinden memnun olduğumuzu ve verilen herhangi bir işlevin değişmezliğine ve yanılmazlığına ne kadar güven duyduğumuzu belirlemeye çalışmaktan ziyade, tüm testleri her zaman çalıştırma kuralına sahip olmak daha kolaydır.

Ve işlem süresi ucuzdur. Birçok kez çoğaltılmış olsa bile, kaydedilen bu milisaniye, sormak için her fonksiyonla zaman ayırmayı haklı kılmak için neredeyse hiç bir şey katmıyor: bir daha asla test etmemize gerek duyduğumuza güveniyor muyuz?

Diğer cevaplarda söylenen her şey doğru, ama bir tane daha ekleyeceğim.

belgeleme

Birim testler, iyi yazılmışsa, geliştiriciye bir işlevin tam olarak ne yaptığını, girdi / çıktı beklentilerinin ne olduğunu ve daha da önemlisi hangi davranıştan beklenebileceğini açıklayabilir.

Bir hatanın tespit edilmesini kolaylaştırabilir ve karışıklığı azaltabilir.

Herkes polinomları, geometriyi ve hatta cebiri hatırlamıyor :) Ama sürüm kontrolünde yapılan iyi bir birim testi benim için hatırlayacaktır.

Dokümantasyon olarak ne kadar yararlı olabileceğinin bir örneği için Yasemin girişine bakın: http://jasmine.github.io/edge/introduction.html Yüklemek için birkaç saniye bekleyin , sonra altına kaydırın. Tüm Yasemin API'sini birim test çıktısı olarak belgelendiğini göreceksiniz.

[@Warbo'nun geri bildirimlerine dayanarak güncelleme] Testlerin güncel olmaları garanti edilir, çünkü yapılmazlarsa, başarısız olurlar, bu genellikle CI kullanılırsa bir derleme hatasına neden olur. Harici dokümantasyon koddan bağımsız olarak değişir ve bu nedenle mutlaka güncel değildir.

Gerçeklik kontrolü

Bütçeleme ve programlama sırasında testin "zaman kaybı" ve ardından müşteri hatalarla uğraşırken "kalite güvencesinin temel bir parçası" olduğu zorlu ortamlarda bulundum, bu yüzden fikrim diğerlerinden daha akıcı.

Bütçen var. İşiniz, bu bütçeyle elde edebileceğiniz en iyi ürünü elde etmek, hangi “en iyi” tanımı ne olursa olsun birlikte kazıyın (tanımlaması kolay bir kelime değil). Hikayenin sonu.

Test, envanterinizde bir araçtır. Kullanmalısınız, çünkü uzun bir milyonlarca tasarruf geçmişinde, hatta belki de milyarlarca dolara sahip iyi bir araçtır . Eğer bir şans verilirse, bu basit fonksiyonlara testler eklemelisiniz. Bir gün cildinizi kurtarabilir.

Ancak gerçek dünyada, bütçe ve zamanlama kısıtlamaları ile, bu gerçekleşmeyebilir. Kendinizi işlem için bir köle yapmayın. Test fonksiyonları gayet güzel, ancak bir noktada, çalışma saatleriniz kod geliştiriciden daha ziyade kod yazarak dökümantasyon dökümanları yazmakla daha iyi harcanabilir. Ya da kod tabanını yeniden gözden geçirerek daha iyi harcanması daha iyi olabilir, bu yüzden bir canavarı zorlamak zorunda kalmazsınız. Veya belki de o zaman patronunuzla bütçe ve program hakkında konuşmak için daha iyi harcanır, böylece bir sonraki finansman turu boruya indiğinde ne için teklif verdiklerini daha iyi anlar.

Yazılım geliştirme bir dengedir. Vaktinizi harcamanın daha iyi bir yolu olmadığından emin olmak için, yaptığınız her şeyin fırsat maliyetini daima hesaba katın.

Evet, testleri sürdür, çalıştırmaya devam et ve devam et.

Birim testleri sizi (ve diğerlerini) kendinizden (ve kendilerinden) korumak için vardır.

Testler neden iyi bir fikirdir?

• Yeni gereksinimler ve ek işlevler karşısında önceki gereksinimlerin işlevselliğini doğrulayın
• Yeniden düzenleme alıştırmalarının doğru olduğunu onaylayın
• Dahili dokümantasyon - kodun kullanılması bekleniyor mu?
• Regresyon testi, işler değişiyor
  • Değişiklikler eski kodu bozuyor mu?
  • Değişiklikler mevcut işlevler veya kod için daha fazla değişiklik isteği veya güncellemesi gerektiriyor mu?
• Testlerin zaten yazılmış olduğu göz önünde bulundurulursa; bakım maliyetlerini daha da azaltacak, hali hazırda harcanan zaman ve paradır

Geliştirici Belgeleri

• (Başka bir geliştirici olarak) bunun test edildiğini nasıl bilebilirim?
• Ben bir hata düzeltmek istiyorsanız müstakil fonksiyonu, nasıl ben zaten kabul ettiğini bir hata tanıtan değilim biliyoruz?
• Karmaşıklık göstergesi: Test sayısı, bir şeyin ne kadar karmaşık olduğu konusunda iyi bir ölçü olabilir. Bu, dokunmamanız gerektiğini, olgun ve stabil olması veya şişirilmesi ve bağlanması gerektiğini gösterebilir.

Kullanıcı Belgeleri

• Zayıf dokümanda, {sıfır, negatif değerler, boş kümeler, vb. Kabul edilip edilmediğini ve beklenen geri dönüş değerinin ne olduğunu görebilir ve görebilirim.
• Ayrıca, nesneyi / işlevi nasıl kullanmam gerektiğine dair iyi bir örnek verir.