“Passing / Broken build” göstergesine alternatif mi?

Her bir taahhütte testleri yürüten sürekli bir entegrasyon olduğunda, ortak bir en iyi uygulama tüm testlerin her zaman geçmesini sağlamaktır (diğer bir deyişle "derlemeyi kırmayın").

Bununla ilgili bazı problemler buluyorum:

Örneğin, biletlere karşılık gelen testler oluşturarak açık kaynaklı bir projeye yardımcı olamazsınız. Başarısız test içeren bir açık kaynak projesine bir Çekme İsteği önerirsem, derleme başarısız olarak işaretlenir ve proje, "derlemeyi bozacağı" için depoya birleştirilmesini istemez.

Ve ben senin repo başarısız testleri için kötü bir şey olduğuna inanmıyorum , bu izleyicide açık sorunları olması gibi. Bunlar düzeltilmeyi bekleyen şeyler.

Aynı şey bir şirket için de geçerli. TDD ile çalışıyorsanız, testleri yazamaz, testi gerçekleştiren mantık kodunu kaydedemez ve yazamazsınız. Bu, dizüstü bilgisayarımda 4-5 test yazdıysam, tatile gitmeden önce bunları taahhüt edemem demektir. Kimse işimi geri alamaz. Bunları, örneğin e-posta ile göndermek dışında bir iş arkadaşınızla "paylaşamıyorum". Ayrıca, bir kişi testleri yazarken diğeri ise modeli yazmayı önler.

Bütün bunlar, derleme işlemini / sürekli entegrasyonu yanlış mı / yanlış mı anlıyorum? Bana öyle geliyor ki, "geçme" / "geçmeme" çok dar bir göstergedir.

Sürekli entegrasyonu ve TDD'yi uyumlu hale getirmenin bir yolu var mı?

Belki "Yeni testler" (yani başarısız olabilir) ve "regresyon testleri" (yani gerektiğini ayırt etmek için bir standart çözüm / uygulama yoktur değil onlar işe kullanılan çünkü başarısız)?

Nereye gittiğinizi görüyorum, ancak bu tür sorunlar genellikle başka şekillerde çözülür. Bunun standart protokol olması için iyi bir neden var. Birisi derlenmeyen bir kod gönderirse, kodunu güncelleyen herkes derlenmeyen bir programa sahip olacaktır . Bu, şu anda tamamen farklı bir şey üzerinde çalışan ve bir şekilde üzerinde çalıştıklarını derleyip test etmeden önce beklemeleri gereken bir durumda bulunan programcıları da içerir.

Standart protokol, programcıların gerektiğinde kodlarını her gün güncelleyebilmeleri için derledikleri sürece , tam veya eksik çalışma için bile değişiklik yapabilmenizdir.

Ancak, hala ne elde ettiğinizi görüyorum. Bazen kodunuzu kaydetmek için taahhütte bulunabilirsiniz . Bunun için çoğu kaynak deposu dallanmayı destekler. Bu, özel bir dal oluşturmanıza, başkalarını rahatsız etmeden üzerinde çalışmanıza, ardından iş tamamlandığında bagajda birleşmenize izin verir. Bu, yapının bozulmasına neden olan herhangi bir boşluk olmadan istediğiniz zaman işlem yapmanızı sağlar.

Bu uygun değilse, GIT yerel makinenizdeki depolara (itmeye) izin verir, ancak muhtemelen depo herhangi bir yerde olabilir. Potansiyel olarak kısmi / eksik iş için bir havuz ve bitmiş iş için başka bir depo oluşturabilirsiniz ve bu depoda her gece bir yapı ekleyebilirsiniz.

Yine, yeterince önemi vurgulayamıyorum. Hiçbir zaman kırık kod gövde için taahhüt etmeyin! Katkılarınız diğer programcıların çalışmalarını etkileyemez.

Düzenle

Kırık testler tasarladığınızı görüyorum, ama benim düşünceme göre, çok az fark var. Bir testin bütün amacı, bir programın belirli bir yönünün geçip geçmediğini belirlemektir. Her zaman başarısız olursa ve hiçbir şey yapmazsanız, geleneksel birim test kullanımında test hiçbir işe yaramaz. Eğer böyle bir test başarısız olursa mutlaka "başarısız" bir taahhüt gerektirmeyen başka bir metrik gerçekleştirmek için kullanırsanız, o zaman aynı şeyi yapmanın başka bir yolunu bulmanızı şiddetle tavsiye ederim.

Aksi takdirde, testin hiçbir zaman dikkate alınmadığını veya derlemenizin başarısız olmasına neden olursa, diğer programcılarınızın başarısız derlemeleri yoksayması riskiniz vardır. Programcıların bir yapıyı kırdıklarında, gerçek bir içgörü sunmayan ve sadece kötü uygulamalarla sonuçlanabilecek bir test yapmaktan fark ettikleri daha önemlidir.

Başarısız testlere sahip bir ana dal verildiğinde, bu listeyi önceki yapılarla karşılaştırmadan - hataları tanıtmadığınızdan nasıl emin olabilirsiniz?

Başarısız testlerin sayısını izlemek yeterli değildir: bir testi düzeltebilir ve diğerini kırabilirsiniz. Ve tatildeyseniz, başarısız yapıya bakan başkaları için net olmayacaktır.

Ana dalınızı her zaman temiz ve yeşil tutun . Bir dalda çalışın. Şubeyi CI altında, ayrı bir işte tutun ve kalbinizin içeriğinde başarısız testler yapın. Sadece ustayı kırma.

Şubenin denetçisine yalnızca tüm testleri geçmesi durumunda şubenizi birleştirtirin. (Daha güçlü: İncelemeyi, şubeyi master'a birleştirmenin sonucu tüm testleri geçerse, şubenizi birleştirebilmesini sağlayın!)

Sürekli entegrasyonla ilgili iyi anlaşılmış ve kabul edilmiş uygulamaları atmadan sorunlarınızı çözmenin yolları vardır.

Bir bilete karşılık gelen bir 'kırık test' yapma sorunuyla başlayacağım. Bir çözüm, sorunu açığa çıkaran bir veya daha fazla kırılma testi oluşturmak, ardından sorunu gerçekten düzeltmektir , böylece ana kod satırına tekrar birleştirilebilirler. İkinci çözüm, kırık testlere sahip olmaktır , ancak yapıyı gerçekten çalıştırmamak ve kırmamak için bir tür yoksayma bayrağı kullanın . Muhtemelen bir yorum veya bunun için kırık bir test olduğunu çok açık hale getiren özel bir açıklama ekleyinTicket#N . Ayrıca biletin kendisine, imzalanmamış ve çalıştırılmayı bekleyen oluşturulan testlere atıfta bulunan bir not ekleyin . Bu, bir kişinin bileti düzeltmesine yardımcı olur, ancak aynı zamanda testten geçen biri için kırmızı bayrak olmaz.

Ve TDD ile bir sonraki probleminize. TDD küçük bir test yazmak ve daha sonra bu testi geçmek için küçük bir kod parçası yazmakla ilgilidir . Ardından, küçük bir işlevsel modülünüz olana kadar yinelemeyi sürdürün. 4-5 test yazarsanız, tatile çıkarsanız yanlış yapıyor olabilirsiniz. Programı birinizle testi, diğeri karşılık gelen kodu yazacak şekilde eşleştirebilirsiniz. Ancak, tamamlanmış bir modül işlenmeye hazır olmadan önce bu kodu ikiniz arasında paylaşmak için ana kod satırı deposunu kullanmamalısınız. Diğerlerinin önerdiği gibi, paylaşılan bir şube sorunlarınızı orada çözecektir.

Sürekli entegrasyon mantrasını kırmaya çalışmak, beklenmedik ve korkutucu yollara yol açabilir. Örneğin, bu tür bir ortamda kod kapsamı ne anlama gelir ? Geliştiriciler sistemin birçok " Bozuk Penceresi " olduğunu nasıl hissetmezlerdi ? Nasıl bir değişiklik yapılır, testi çalıştırır ve gerçekten yeni bir şey kırıp kırmadıklarını, ya da sadece eski şeyleri bilebilir mi?

Bence temel probleminiz test SONUÇLARINI yapının bir parçası olarak dahil etmenizdir. Açıkçası bazı insanlar sizinle aynı fikirde olsa da, diğerleri aynı fikirde değil. Yapıyı kırma, oluşturmadığı zaman gerçekleşir. Hatasız inşa etmediğinde değil.

Windows veya Linux gibi büyük bir projeyi, hatta Firefox gibi bir şeyi düşünün - sence hatasız mı geliyorlar? Tabii ki değil. Şimdi bu projeler TDD yapmıyor, ama bu gerçekten alakasız - TDD iki temel gerçeği değiştirmiyor: hatalar var ve bunları düzeltmek zaman alıyor. Bir projenin (açık kaynaklı veya değil) düşük öncelikli hataları boşa harcayamayacağı zaman. KDE son zamanlarda on yıldan eski bir hatayı düzeltti. En son ne zaman birinin "projemizi göndermek için on yıl beklediğimize sevindim" dediğini duydunuz?

TDD, bir bakıma, muhtemelen hatalarla gemi göndermeyi kolaylaştırır - çünkü kusurun ne olduğunu daha iyi anlarsınız. Hatanın nedenini kesin olarak tanımlayabiliyorsanız, düzeltmenin maliyetini tartmak için mükemmel bir temeliniz vardır.

Benim tavsiyem yeşilin içinde biraz kırmızı olmayan bir proje bulmak.

 > a common best practice is to have all the tests passing (green) at all times.

Tüm testlerin başarısız olmasını (kırmızı değil) tercih ederim .

Bu biraz farklı tanım sayesinde,

• henüz uygulanmadı (NotImplementedException varsa rahibede gri)
• başarısız olduğu bilinen = "yok" ifadesi, testi yok sayıldı olarak işaretleyerek / ek açıklama ekleyerek (sarı)

Bunları depoya kontrol ediyorum, sürekli yapınız bozulmamış ve bu nedenle geçerli değil.

İki farklı CI yapısı "kavramı" düşünebilirsiniz.

1. Düzenli CI yapıları. Düzenli CI derlemesi, yalnızca geçmesi için kodun yazıldığı testleri derlemeli ve çalıştırmalıdır, böylece test geçişi / başarısızlıklarının CI raporları, kodun daha önce kabul edilen durumuna karşı açık, açık bir regresyon göstergesidir.

2. "Gelecek" bir CI derlemesi. Bu derleme, yalnızca hiçbir kodu yazılmamış olan testleri derler ve çalıştırır. Böyle bir teste sahip olmanın birkaç nedeni olabilir:

   • Sorun izleyiciden, henüz düzeltilmeye çalışılmayan belirli hata durumları için testler eklenebilir. Düzeltmeden bile bir sorun için zaten kodlanmış, çalışan bir teste sahip olmak açıkça yararlıdır.

   • Henüz uygulanmamış yeni gerekli işlevler için testler eklendi.

   • Çoğu zaman, bir hatanın veya özelliğin nasıl test edileceğini bilmek, özelliğin veya düzeltmenin nasıl uygulanacağını bilmekten daha kolaydır ve testi kaynak kontrolüne göndererek iki adımı ayırmak, hiçbir bilginin kaybolmamasını sağlamak için yararlı olabilir.

"Standart" CI'de olduğu gibi, düzenli geliştirme rejiminde ekip sadece normal yapının günlük inşa sonuçlarına bakacaktır.

Ekip ayrıca "gelecekteki" CI yapısından test senaryolarının gelişimini de izleyebilir - özellikle de düzenli CI için yapılan herhangi bir değişikliğin gerçekten "önemli" bir gösterge olabilen "gelecekteki" yapının sorunlarını çözüp çözmediğini görmek için altta yatan sorun veya tasarım iyileştirmesi.

Son olarak, bir ekip üyesinin ellerinde fazladan zaman varsa, sorunlardan birini "gelecek" ten düzeltmeye bakabilir ve başarılı olursa "normal" e geçirir (sorun izleyici durumunu güncellerken).

Reponuzda başarısız testlerin yapılmasının kötü bir şey olduğuna inanmıyorum, izleyicinizde açık sorunlar olması gibi. Bunlar düzeltilmeyi bekleyen şeyler.

Sorun testlerin başarısız olmasından kaynaklanmıyor, basit, bağlamsız bir gerileme göstergesi. Aka: Bir geliştirici olarak, tek bir göstergeyi kontrol edebilir ve bir regresyon veya kırılma kodu ekleyip eklemediğimi öğrenebilir miyim.

'Yumuşak' arızalar kavramını tanıttığınız anda (tamam, üzerinde çalışıyoruz / henüz uygulanmadı / yeni sürümü bekliyoruz / bu diğer yapı düzeltildikten sonra tekrar geçecek), ihtiyacınız var beklenen durumu öğrenmek için koşabilecek veya teste bakabilecek herkes. Hangi takım yeterince büyük bir takımda değişecek: göstergeniz anlamsızlaşacak. Daha küçük bir bağlamda (örneğin ekip özel entegrasyon testi), o zaman teknik borç gibi olduğunu ve tamam olduğunu düşünüyorum - sadece yönetilmesi gerekiyor.

'Yeşil / geçiş' olan çoğu araç adresinin yolu, beklenen sonucun ne olduğunu yansıtır - kodun çalıştığını değil:

• Fitness, beklenen başarısızlık kavramına sahiptir.
• JUnit'in @Ignored / @Test vardır (beklemek =)
• Salatalık 'henüz uygulanmadı' (veya her ne denirse) durumuna sahiptir

Bunlar kendi sorunları ile gelirler ('evet, bunun kırıldığını biliyoruz, üzerinde çalışıyoruz' ve 'doğru davranış bir istisnadır' arasında nasıl ayırt edersiniz) - ama yardımcı olurlar.

Atlanmış testler kullanıyorum.

Kullandığım belirli birim test çerçevesinde SkipTest istisnasını yükseltebilirim. Test aslında çalışmaz ve başarısızlığı derlemeyi bozmaz. Ancak, atlanan testlerin sayısını görebilir ve bu alanda yapılacak iş olup olmadığını görebilirim.