Üretimde bir hata bulunduğunda kasten yapıyı bozmalı mıyım?

Son kullanıcılar tarafından üretimde ciddi bir hata bulunursa, bu hatayı kapatmak için başarısız bir birim testinin eklenmesi gerektiği ve bu nedenle hata düzeltilinceye kadar kasten yapıyı bozması benim için mantıklı görünüyor. Bunun mantığı, yapının başından beri başarısız olması gerektiği , ancak otomatikleştirilmiş test kapsamının yetersizliğinden kaynaklanmadığıdır.

Meslektaşlarımdan bazıları, başarısız bir ünite testinin kontrol edilmemesi gerektiğini söyleyerek aynı fikirde değildi. Normal TDD uygulamaları açısından bu bakış açısına katılıyorum, ancak üretim hatalarının farklı şekilde ele alınması gerektiğini düşünüyorum - sonuçta neden izin vermek istiyorsunuz? Bilinen kusurlarla başarılı olmak için bir yapı?

Bu senaryoyu ele almak için başka kanıtlanmış stratejileri olan var mı? Yapının kasıtlı olarak kırılmasının diğer ekip üyeleri için yıkıcı olabileceğini biliyorum, ancak bu tamamen dalları nasıl kullandığınıza bağlı.

Stratejimiz:

Başarısız bir testte kontrol edin, ancak not ile birlikte not verin @Ignore("fails because of Bug #1234").

Bu şekilde, test var, ancak yapı bozulmuyor.

Tabii ki, db dosyasında yok sayılan testi not edin, bu nedenle @Ignoretest düzeltildikten sonra kaldırılır. Bu aynı zamanda hata düzeltme için kolay bir kontrol işlevi görür.

Başarısızlık testlerinde yapıyı kırma noktası bir şekilde takımı baskı altına almak değildir - onları bir sorunla karşı karşıya bırakmaktır. Sorun tanımlanıp DB böceğine dosyalandığında, her derleme için test çalıştırmasının bir anlamı yoktur - bunun başarısız olacağını biliyorsunuzdur.

Tabii ki, hata hala düzeltilmelidir. Ancak düzeltmeyi zamanlamak bir iş kararıdır ve bu nedenle gerçekten dev'in endişesi değildir ... Bana göre, bir hata DB'ye dosyalandığında, müşteri / ürün sahibi bana düzeltilmesini istediğini söyleyene kadar artık benim sorunum değil .

Bir yapının bilinen kusurlarla başarılı olmasına neden izin vermek istiyorsunuz?

Çünkü bazen, zaman kısıtlamalarınız olur. Veya böcek o kadar küçüktür ki, birimin test edilmesi ve düzeltilmesi için gereken birkaç gün boyunca ürünün sevkiyatını geciktirmeye değmez.

Ayrıca, her hata bulduğunuzda kasten yapıyı kırmanın amacı nedir? Bulduysanız, tüm ekibinizi rahatsız etmeden düzeltin (veya düzeltecek kişiye atayın). Bir hatayı düzeltmeyi hatırlamak istiyorsanız, hatayı izleme sisteminizde çok önemli olarak işaretlemeniz gerekir.

Sorunları tekrar ortaya koymamanızı (-) istemediğiniz için testler yapılır. Başarısız olan testlerin listesi, hata izleme sisteminin yerine geçmez. POV'da başarısızlık testlerinin sadece hataların belirtilmesi değil, aynı zamanda gelişim süreci başarısızlığının (dikkatsizlikten kötü tanımlanmış bağımlılığa kadar) bir göstergesi olmadığına dair bir geçerliliği vardır.

"Yapıyı kırmak", bir yapının başarıyla tamamlanmasını önlemek anlamına gelir . Başarısız bir test bunu yapmaz. Yapının bilinen bir kusur olduğunu ve bunun tam olarak doğru olduğunu gösterir.

Çoğu derleme sunucusu, testlerin zaman içindeki durumunu izler ve bir regresyona (eklendiğinde ve artık geçmeyen testlerde) eklendiğinden beri başarısız olan bir teste farklı bir sınıflandırma atayacaktır ve gerileme gerçekleşti.

Başarısızlık testinin eklenmesi gerektiğini, ancak açıkça “başarısızlık testi” olarak nitelendirilmemesi gerektiğini savunuyorum.

@ BenVoigt'ın cevabında işaret ettiği gibi , başarısız bir test mutlaka " yapıyı bozmaz " anlamına gelmez. Sanırım terminoloji takımdan takıma değişebilir, ancak kod hala derlenir ve ürün hala başarısız bir testle gönderilebilir.

Bu durumda kendinize sormanız gereken şey,

Başarılması gereken testler nelerdir?

Testler yalnızca herkesin kod hakkında iyi hissetmesini sağlamak için varsa, o zaman herkesin kod hakkında kötü hissetmesini sağlamak için başarısız bir test eklemek verimli olmaz. Fakat o zaman, ilk etapta testler ne kadar verimli?

Benim iddiam, testlerin işletme gereksinimlerinin bir yansıması olması gerektiğidir . Bu nedenle, bir gereksinimin gerektiği gibi karşılanmadığını gösteren bir "hata" bulunursa , testlerin işletme gereksinimlerini doğru veya tam olarak yansıtmadığının da bir göstergesidir.

İlk önce düzeltilmesi gereken böcek budur . "Başarısız bir sınav ekleyemezsin". Sen ediyoruz düzelten iş gereksinimlerine daha doğru bir yansıması için testler. Kod o zaman bu testleri geçemezse, bu iyi bir şeydir. Testlerin işlerini yaptığını gösterir.

Kodu düzeltmenin önceliği işletme tarafından belirlenecektir. Ancak testler düzeltilinceye kadar, bu öncelik gerçekten belirlenebilir mi? İş, tam olarak neyin başarısız olduğu, neyin başarısız olduğu ve kararlarını öncelikli olarak almak için niçin başarısız olduğu bilgisi ile donanmış olmalıdır. Testler bunu belirtmelidir.

Tamamen geçmeyen testleri yaptırmak kötü bir şey değil. Önceliklendirilmesi ve buna göre ele alınması bilinen sorunların büyük bir eseridir. Ancak, tamamen test edilmeyen testlere sahip olmak bir problemdir. Testlerin değerini sorgulamaya çağırıyor.

Başka bir şekilde söylemek gerekirse ... Yapı zaten bozuldu. Karar verdiğiniz tek şey, bu gerçeğe dikkat edip etmemek.

Test otomasyon ekibimizde, testteki bir hatadan ziyade üründeki bir kusurdan dolayı başarısız oldukları sürece başarısızlık testlerini kontrol ederiz. Bu şekilde, dev ekip için kırdıklarına dair kanıtımız var. Yapıyı kırmak oldukça kaşlarını çattı, ancak bu kusursuz bir şekilde derlenebilir ama başarısız testler yapmakla aynı şey değil.

Hata giderilinceye kadar başarısız olacağını bildiğiniz bir testin yazılması iyi bir fikirdir, TDD'nin temelidir.

Yapıyı kırmak kötü bir fikir. Neden? Çünkü hiçbir şey sabitlenene kadar devam edemez demektir. Esasen kalkınmanın diğer tüm yönlerini engeller.

Örnek 1
Uygulamanız birçok bileşenden farklıysa ne olur? Peki ya bu bileşenler kendi serbest bırakma döngüsüne sahip diğer ekipler tarafından çalışıyorsa? Zorlu! Hata düzeltmenizi beklemek zorundalar!

Örnek 2
İlk hatanın düzeltilmesi zorsa ve daha yüksek önceliğe sahip başka bir hata bulursanız ? İkinci böceğin yapısını da bozar mısınız? Artık ikisi de düzeltilene kadar inşa edemezsiniz . Yapay bir bağımlılık yarattınız.

Testin başarısız olmasının bir yapıyı durdurmasının neden mantıklı bir nedeni yoktur. Bu, geliştirici ekibin (belki de yönetim tartışmasıyla birlikte) bilinen hatalara sahip bir derleme yayınlamanın artılarını ve eksilerini tartıştırarak yapması gereken bir karardır. Bu, yazılım geliştirmede çok yaygındır, hemen hemen tüm ana yazılımlar en azından bilinen bazı konularla birlikte yayımlanır .

Bu, testlerin oynaması gereken rolüne ve sonuçlarının kabul edilen inşa sistemini / süreci nasıl etkilemesi gerektiğine bağlıdır. Yapıyı kırma anlayışım Ben'inkiyle aynı ve aynı zamanda mevcut testleri kıran kodu da bilerek kontrol etmemeliyiz. Eğer bu testler "sonradan" geldiyse, başkalarını gereksiz yere daha az yıkıcı hale getirmek için onları görmezden gelmek "tamam" olabilir, ancak başarısız testlerden yoksun bırakma (bu şekilde göründüğü gibi) uygulamalarını rahatsız edici (özellikle öyle) buluyorum. ünite testleri için), bu testleri ne kırmızı ne de yeşil olarak göstermenin bir yolu olmadığı sürece.

Tabii ki, bu hataya bağlıdır, ancak genellikle manuel veya otomatik test sırasında tanımlanmayan bir şey yanlış giderse, bu durum kapsama alanında bir boşluk olduğunu gösterir. Kök nedenini bulmayı ve sorunun üzerine bir birim test vakasını koymayı kesinlikle teşvik ederim.

Bir bakım branşından sıcak bir düzeltme yapılması planlanan bir üretim sorunu ise, düzeltmenin ana hat üzerinde çalıştığından ve geliştiricinin, aşırı derecede bir birleştirme çatışması çözümü ile düzeltmeyi yanlışlıkla gideremeyeceğinden emin olmanız gerekir. .

Ek olarak, yayın politikanıza bağlı olarak, yeni güncellenen ünite testlerinin varlığı, bir geliştiricinin sorunu değiştirmek yerine, sadece [(sorun veya testler?)] Değiştirmek yerine sorunu çözdüğünü doğrulamaya yardımcı olabilir. Yeni birim testlerinde doğru gereksinimleri.

Yapıya bir başarısızlık testi eklenmesiyle ilgili bir sorun, ekibinizin başarısız testlerden yoksayma alışkanlığıyla karşılaşabilmesidir; Yapım sisteminize bağlıdır, ancak başarısız bir test her zaman "bir şey kırılmış" anlamına gelmiyorsa, başarısız testlere daha az dikkat etmek kolaydır.

Takımınızın bu zihniyete girmesine yardımcı olmak istemezsiniz.

Bu yüzden testi eklemeniz gerektiğine katılıyorum , ancak hata giderilinceye kadar otomatik derleme amacıyla 'yok sayılmış ' olarak işaretleyin .

Bence bir şekilde testi bir hata olarak 'kontrol etmelisin', bu yüzden bunu düzelttiğinde tekrar olmaz ve bir şekilde öncelik sırasına koyarız, bence yapıyı bozmamak en iyisidir. . Bunun nedeni, müteakip inşa komisyonlarının, kırık testinizin arkasına gizlenmesidir. Bu nedenle, bu hata için kırık bir teste bakarak, tüm ekibin bu hatayı düzeltmek için çalışmalarını bir kenara koymasını talep edersiniz. Bu olmazsa, bu şekilde izlenemeyen ihlal komisyonları ile sonuçlanabilirsiniz.

Bu yüzden beklemede olan bir test olarak kabul etmenin ve ekibinizde beklemede olan testlere girmemek için bir öncelik haline getirmenin daha iyi olduğunu söyleyebilirim.

Diğer bir seçenek ise başarısızlık testini kaynak kontrol sisteminizde ayrı bir branşta kontrol etmektir. Uygulamalarınıza bağlı olarak, bu uygun olabilir veya olmayabilir. Bazen devam etmeyen işler için önemsiz olmayan bir hatayı düzeltmek için yeni bir şube açıyoruz.