Her yeni hata için bir birim testi ekle

İşimde, bir hatayı gideren tüm geliştiricilerin bu tür hatalar hakkında uyarıcı yeni bir birim testi eklemek zorunda kalmaları gerekir (tekrar oluşması durumunda). Birim testi mümkün değilse (örneğin, bir web sayfası tasarımı sorunu), KG departmanının manuel olarak kontrol etmek için bir test durumu oluşturması gerekir.

Bunun arkasındaki fikir, ürünün piyasaya sürülmesinden önce bir kusur tespit edilmemişse, tespit etmek için uygun bir birim testinin olmamasıdır. Bu yüzden geliştirici eklemek zorunda.

Soru şudur: Herhangi bir yazılım geliştirme metodolojisinde bu yaygın mıdır? Bu tekniğin bir adı var mı? Bu konuda daha fazla şey öğrenmek istiyorum, ancak başlamak için biraz bilgiye ihtiyacım var.

Bu oldukça yaygındır. Bunu ekibimizde kullanıyoruz. Her üretim hatası için, geliştirici sorunun nedenini belirten bir not eklemeli, başarısız bir ünite testi eklemeli ve bilet kodu kontrol etmek üzere dev durumuna getirmeden önce bir test etkisi analizi eklemelidir.

Arızalı ünite testi, kodu üretime sokmadan önce geçmelidir.

Bunun genel "regresyon testi" dışında belirli bir adı olduğunu sanmıyorum. Bu çok kullanışlıdır ve bu süreci takip etmeye başladıktan sonra ürünün kalitesinde bir artış görmeye başladık.

Kesinlikle!

Birim testlerinin iyi bir şey olduğu konusunda hemfikirseniz, o zaman bir hata varsa, o kod yolunu kapsayan eksik bir birim testi olduğunu anlayacaksınız.

Öyleyse ne olması gerektiği, hatanın var olduğunu gösteren bir ünite testi yazıyorsunuz, fiili hatayı düzeltiyorsanız, ünite testi geçecek.

Eğer hiç bir birim testiniz yoksa, o zaman bir projeye birim testleri uygulamaya başlamanın iyi bir yolu olabilir.

Teknik, test odaklı geliştirmedir. Bu bir dahaki sefere benzer bir hatayı tespit edebilmekle ilgili bir şey değil, yinelenebilir testler paketi her zaman faydalı olsa da. Mesele şu ki, kodda yanlış olanı izole ettiğinizi, yanlış olduğunu, düzeltildiğini, düzeltmenin doğru olduğunu kanıtladığınızı gösterebilirsiniz.

Oldukça hatırlayamadığım veya bulamadığım bir alıntı var, ancak kabaca şöyle: "Her böcek henüz yazılı olmayan bir sınavdır."

Bir regresyon testi olarak satmaya çalışmak IMHO, kaybedilen bir savaştır. Bu şeylerin ne kadar nadiren tekrarlanan bir hatayı yakaladığı göz önüne alındığında, çoğu geliştirici, "Basitçe düzeltirken neden canımı sıkıyor?"

Bu teknik oldukça yaygındır ve, bence, bunun için en iyi isim “Kusur Driven Test” dir (onunla kendim geldi ve o zaman bu ad altında açıklanan bulundu uzun zaman önce ).

Bazen bazı kişilerin bu sınamaları “Regresyon Sınamaları” olarak adlandırdığını görebilirsiniz, ancak şahsen bu adı doğrulamak için biraz zor buluyorum. “Regresyon testi” nin biraz daha yaygın bir tanımı (ve muhtemelen tartışmalı bir şekilde bu isim için daha anlamlı olan bir tanım) “regresyon testi”, “herhangi bir gerileme sağlamadığınızdan emin olmak için kodda herhangi bir değişiklik yaptıktan sonra testler yapılması” ve CI’nızdır. Her şubeyi depoya bastırarak test eder, onu tatmin eder.