Kırık Eski / Eski Birim Testleri

Büyük bir şirkette çalışıyorum ve binlerce junit testiyle büyük bir java uygulamasından sorumluyum. Bu role geçtiğimden beri 200-300 kırık test yapıldı (muhtemelen yıllarca kırıldı). Testler eski ve kırılgandır ve tipik olarak canlı sanal alan verileriyle biten spagetti bağımlılıklarının bir karışıklığıdır.

Amacım% 100 geçiş testlerinden geçiyor, böylece birim test hatalarını derleyebiliyoruz, ancak kırık testlere değinene kadar yapamam. Çok az bütçem var, çünkü bakım bütçesi öncelikle destek amaçlıdır, ancak ekibim düşük asılı meyve testlerini (çoğunlukla yapılandırma / yerel kaynak sorunları) belirledi ve düzeltti ve 30-40 gerçekten çirkin testlere düştük.

En iyi uygulama hakkında bazı görüşler nelerdir? Testlerin değerli olduğunu düşünmüyorum, ama aynı zamanda neyi test ettiklerini veya neden kazmadan çalışmadıklarını da bilmiyorum, ki bu muhtemelen sahip olmadığımız zaman ve para gerektiriyor.

Kırık testlerin durumlarını bildiğimiz herhangi bir şeyle belgelemeliyiz, sonra kırık testleri tamamen silin veya yok sayın ve araştırmak ve düzeltmek için daha düşük öncelikli bir hata / iş öğesi girin. Daha sonra% 100'de olacağız ve diğer testlerden gerçek değeri almaya başlayacağız ve bir bakım / yeniden düzenleme rüzgarımız varsa bunları tekrar alabileceğiz.

En iyi yaklaşım ne olurdu?

Düzenleme: Ben bu sorudan farklı bir soru olduğunu düşünüyorum, çünkü biz ileriye yazılması gereken testler için açık bir yön var, ama ben büyük mevcut testler anlamlı hale gelmeden önce ele almak için eski başarısız testler miras.

Ne yapacağım ilk önce başarısız ve her zaman başarısız olan testleri devre dışı bırakmak.

Başarısız bir test yapın.

Araştırırken, şirketinizle birlikte olan insanlara daha uzun sorular sorabilirsiniz, bunlar hakkında belgeleyebileceğiniz / yakalayabileceğiniz çok sayıda kabile bilgisi olabilir. Belki VCS kayıtlarınızdan. "Ah, X'e yükselttiğimizden beri bu test her zaman başarısız oldu" ya da diğer bilgiler yararlı olabilir.

Test edilen işlevselliğin ne olduğunu öğrendikten sonra şunları belirleyebilirsiniz:

• Bunun test edilmesini önemsiyor muyuz
• Bunun test edilmesi ne kadar önemli?

Ve sonra bir öncelik listesi yapın.

Muhtemelen bu listedeki hiçbir şey yıllarca göz ardı edildiğinden daha sonra daha fazla zaman alacak kadar önemlidir. Bu yüzden tüm bu kırık testleri belgelemek ve analiz etmek için çok fazla zaman / kaynak harcamam .

Aşağıdakileri yaparım:

1. Başarısız testlerin tam olarak neyi doğrulamaya çalıştığını belirlemeye çalışın.

2. Triyaj - Bazı testler dünyanın (eski) durumu gibi önemsiz şeyleri test etmeye çalışıyorsa, bunları silin. Bazılarının önemli bir şeyi doğrulamaya çalıştığını fark ederseniz, bu testlerin doğru bir şekilde yapılıp yapılmadığını belirlemeye çalışın. Yanlış test yapıyorlarsa, doğru test etmelerini sağlayın.

3. İyi testlere sahip olduğunuz için üretim kodunuzdaki yanlışları düzeltin.

Muhasebeyi hatırlayın, her kod satırı bir yükümlülüktür, ancak bir varlık olarak yanlış değerlendirilebilir. deleteAnahtar firma için değer oldukça zorlaşır.

200-300 kırık test (muhtemelen yıllarca kırık).

Ah! Bir kez benzer bir durumla karşılaştım, ancak 7 testin başarısız olduğu, ekibin "her zaman gevrek" zihniyet nedeniyle aylarca başarısız olduklarını görmezden gelmeye başladığı yerde.

Amacım% 100 geçiş testlerinden geçiyor, böylece birim test hatalarını derleyebiliyoruz, ancak kırık testlere değinene kadar yapamam.

Takımda sadece genç bir geliştirici olmama rağmen benzer bir hedefe takıntılıydım çünkü aylar boyunca daha fazla testin başarısız olduğu bir yığın fark ettim. Bunları "uyarılar" dan derleme hatalarına (belki de ekibin geri kalanına biraz iğrenç bir şekilde) dönüştürmemizi istedim.

Kırık testlerin durumlarını bildiğimiz herhangi bir şeyle belgelemeliyiz, sonra kırık testleri tamamen silin veya yok sayın ve araştırmak ve düzeltmek için daha düşük öncelikli bir hata / iş öğesi girin. Daha sonra% 100'de olacağız ve diğer testlerden gerçek değeri almaya başlayacağız ve bir bakım / yeniden düzenleme rüzgarımız varsa bunları tekrar alabileceğiz.

Bunlar da benim düşüncelerim. Tüm bu hatalı testleri geçici olarak devre dışı bırakabilir ve yavaşça ziyaret edebilir ve zaman içinde düzeltebilirsiniz. Gerçi düşük öncelikli olsalar bile, gerçekten önemli olduğunu düşünüyorsanız bu düzeltmeleri planlamak önemlidir, çünkü bu tür öğelerin düzeltilmemesi kolaydır. Benim için öncelik, başarısız olan yeni testlerin yapılmamasını sağlamaktır.

Her türlü uyarı gibi, yapıyı bozmazlarsa, hızla yığılmaya eğilimlidirler. Bu, uyarıları göz ardı etme alışkanlığının (bu durumda başarısız testler) hızla daha fazla uyarının verilmesine yol açabileceği ve bu uyarıları sıfıra tutma cazibesini azaltabileceği bu tür bir takım dinamik olduğunu varsayar.

Çok vicdani ekip bu sorunları muzdarip ve (testlerde yeni başarısızlıkları) yeni uyarılar almaktan kaçınması, ama biraz daha sert gidip hataları içine bu çevirerek bir önleme stratejisi egzersiz kesinlikle daha güvenlidir olmayabilir gerekir a öncesinde sabitlenebilir birleştirme işlemi.

Bu yüzden benim önerim seninkiyle aynı (sadece güçlü bir fikir olsa da - belki bir şekilde bunu metriklerle ve daha bilimsel bir cevapla destekleyebilir). Bu eski testleri devre dışı bırakın ve sonunda düzeltmek için programa koyun. İlk öncelik, şu anda başarılı olan testlerin sonuçta başarısızlığa uğrarsa yok sayılmayacağından emin olarak bu sorunun yığılmamasına ve daha da kötüleşmemesine dikkat etmektir.

Bir şekilde şanslısın. Başarısız olan ve olmaması gereken testlere sahip olmak (en azından bir şeylerin yanlış olduğuna dair bir uyarı verir) geçmek ve olmamak üzere (yanlış bir güvenlik hissi vermek) testlere sahip olmaktan daha iyidir.
Tabii ki öncekine sahipseniz, ikincisine de sahip olmanız muhtemeldir (bu yüzden testler başarılı ancak başarısız olmalıdır).

Daha önce belirtildiği gibi, şimdilik bu başarısız testleri devre dışı bırakın, ancak test günlüğünüzde sürekli bir hatırlatma olarak bir mesaj yazdırmalarını sağlayın.
Ancak, geçen ve geçmemesi gereken testleri bulmak ve ayıklamak için tüm test paketinizin üzerinden geçecek kaynakları kesinlikle bulmalısınız, çünkü her biri, kodunuzda şu anda algılayamadığınız bir hata olduğu anlamına gelir. test çevrimleri.

Kod tabanının üzerinde asılı olan bu karanlık bulutu kullanarak, testlerinizi tam olarak incelemek için biraz bütçe elde edebilirsiniz, eğer doğru oynarsanız ve sadece bazı testlere bakılması gerektiğini düşündüğünüzü söylemezseniz, yapmamaları durumunda başarısız olurlar, ancak testlerinizin kodunuzdaki hataları doğru bir şekilde algıladığına güvenmediğinizden, test kümesine işini yapmak için güvenilemeyeceğinden emin değilsiniz.
Önceki bir şirkette böyle bir inceleme için çalıştığımda, kodun ne yaptığına dair yanlış varsayımlarla yüzlerce testin yazıldığını, kodun (aynı yanlış varsayımlar kullanılarak yazıldığı) yol açtığı zaman testleri geçtiğini buldum. gerçekten olmamalı. Bunu düzeltmek, (çoğu kritik olmasa da) bazı önemli sistemleri yıkmış olabilecek kötü bir köşe davası hatasını çözdü.

Başarısız bir birim testi yapının bozulmasına neden olmalıdır. Bunu gerçekleştirmeniz ve bu hedefi belirlemeniz için iyi. İnsan aklı, kalıcı bir yanlış alarm kaynağından daha fazla hiçbir şeyi göz ardı edemez .

Bu testleri atın ve geriye bakmayın. Yıllardır başarısız oluyorlarsa ve şu ana kadar ele alınmamışlarsa, o zaman bir öncelik değildir.

Aşiret bilgisine gelince, aşiret bilgisine sahip insanlar hala etraftalarsa, şimdiye kadar başarısız testleri düzeltmelilerdi. Değilse, yine, bunlar bir öncelik değildir.

Aşiret bilgisi yoksa, siz ve ekibiniz mantığın sahipliğini almak zorundasınız. Başarısız testler yardımcı olmaktan daha yanıltıcı olabilir - dünya ilerlemiş olabilir.

Alakalı yeni testler oluşturun ve mükemmel kodlar yazmaya başlayın.