Muazzam sayıda başarısızlık testi ile nasıl baş edilir? [kapalı]

Java ile yazılmış eski bir projenin geliştirilmesinde çalışıyorum. 10 milyondan fazla LOC ve daha da kötüsü 4000'den fazla fonksiyonel testimiz var.

Hudson tarafından planlanan testler her büyük kod değişikliğinde deli gibi başarısız oluyor. Test başarısızlığının doğrulanması - eğer üründe veya testte bir sorun varsa, aylar alır. Eski testleri kaldıramayız çünkü ne test ettiklerini bilmiyoruz!

Ne yapabiliriz? Bu tür eski testlere nasıl devam edilir?

Onları terk et.

Üretmek için çok çaba sarf eden bir şeyden vazgeçmenin zor olduğunu biliyorum, ancak testler sizin için çalışmıyor, size karşı çalışıyorlar. Bir test odasının, sistemin yapması gerekeni yaptığı konusunda size güven vermesi beklenir. Bunu yapmazsa, varlık yerine borçtur. Sistemin veya testlerin hatalı olup olmadığının önemi yoktur - test takımının çalıştırılması çok fazla hata bildirdiğinde, amacını yerine getiremez.

Şimdi ihtiyacınız olan şey, hatasız çalışan yeni bir test paketi . Bu, başlangıçta çok az kapsama sahip olacağı anlamına gelir, aslında neredeyse hiç kapsama alanı yoktur. Sisteminizle ilgili bir şeyi tam olarak anlamak veya zaman ayırmak için bu bilgiyi bir sınamada yeniden sıralarsınız. Zamanla, bu gelecekte geliştirebileceğiniz yeni bir güvenlik ağı üretecektir. Eski, anlaşılmamış bir güvenlik ağını yama yapmaya çalışmak neredeyse hiç değmeyecek bir zaman dilimidir.

Testleri eski süitlerden yeni süitlere transfer etmeyi bile savunurdum. Elbette, bazıları şimdi başarılı olabilir, ancak test etmek zorunda oldukları şeyi tam olarak test ettikleri için mi, yoksa sadece rastgele atışların hedefi vurduğu için mi? Açıkçası, harcayabileceğiniz çabayla yapabilecekleriniz ve yapamadıklarınız konusunda pragmatik olmalısınız, ancak bir test odasının işini yapmak için temiz bir şekilde çalışması gerektiği konusunda ödün veremezsiniz .

Git ve testleri düzelt.

En büyük hatan, testlerin başarısız olmasına izin vermen ve belli bir süre bunu görmezden geldin. Sahip olduğun şey "eski testler" değil - eski bir kod üzerinde çalışıyorsun. Ve testler olmadan yazılan her kodun eski olduğunu düşünüyorum.

Test hatasının doğrulanması - eğer üründe veya testte sorun varsa, aylar alır. Eski testleri kaldıramadık çünkü ne test ettiklerini bilmiyorduk!

Net gereksinimlerle çalışmadığınız için kuruluşunuzda daha da büyük bir sorun var gibi görünüyor. Sizin (veya bir başkasının) doğru davranışı onaylayamadığını anlayamıyorum.

Testler değerlidir. En azından, birisinin onları yazmak için zaman harcaması gerektiğini düşündüklerini kaydeder, bu yüzden bir zamanlar birileri için bir değeri olabilir. Şansınız varsa, ekibin üzerinde çalıştığı tüm özelliklerin ve hataların tam bir kaydını içereceklerdir - ancak dikkatlice düşünülmeden keyfi bir test kapsamı numarasına ulaşmanın bir yolu olabilirler. Onlara bakana kadar, burada hangi durumda olduğunu bilemezsiniz.

Testlerinizin çoğu zamanın çoğunu geçerse, o zaman sadece mermiyi ısırın ve başarısız olan birkaç testin ne yapmaya çalıştığını bulmak için zaman harcayın ve bir dahaki sefere işin daha kolay olması için bunları düzeltmek veya geliştirmek için zaman ayırın. Bu durumda, az sayıdaki başarısızlık testi ile ne yapılması gerektiğine dair bir tavsiye için, her bir test bölümünün amacını belirleme bölümüne atlayın .

Öte yandan, şu an Kırmızı bir yapıyla, bir süredir geçmemiş yüzlerce hatta binlerce testle karşı karşıya kalabilirsiniz ve Jenkins uzun zamandır Yeşil değildi. Bu noktada, Jenkins inşa durumu işe yaramaz hale geldi ve check-in işleminizle ilgili sorunların önemli bir göstergesi artık çalışmıyor. Bunu düzeltmeniz gerekir, ancak oturma odanızdaki karmaşayı toparlarken tüm ilerlemeyi durduramazsınız.

Başarısız olan testlerden hangi değerin geri kazanılabileceğini belirlemek için gerekli arkeolojiyi yaparken akıl sağlığınızı korumak için, aşağıdaki adımları öneriyorum:

Başarısız olan testleri geçici olarak devre dışı bırakın.

Bunu açıklayamayacağınız, ortamınıza bağlı olarak yapabileceğiniz birkaç yol var, ki açıkça tanımlamıyorsunuz, bu yüzden belirli bir tanesini gerçekten tavsiye edemiyorum.

Bazı çerçeveler beklenen hatalar kavramını desteklemektedir. Sizinkine göre, o zaman bu harika, çünkü bu kategoride kaç testin kaldığına dair bir geri sayım göreceksiniz ve hatta bazıları beklenmedik bir şekilde geçmeye başlarsa size bilgi verilecek.

Bazı çerçeveler test gruplarını destekler ve Hudson'a yalnızca bazı testleri çalıştırmasını ya da bir test grubunu atlamasını söylemenizi sağlar. Bu, zaman zaman geçip geçmediğini görmek için test grubunu el ile çalıştırabileceğiniz anlamına gelir.

Bazı çerçeveler, Yok Sayılacak tek testleri açıklama eklemenize veya başka türlü işaretlemenize izin verir. Bu durumda onları grup olarak çalıştırmak daha zordur, ancak sizi rahatsız etmelerini önler.

Testleri normalde derlemede bulunmayan bir kaynak ağacına taşıyabilirsiniz.

Ekstremitede, kodu sürüm kontrol sisteminin HEAD'sinden silebilirsiniz, ancak bu daha sonra üçüncü fazın ne zaman tamamlandığını tanımayı zorlaştırır.

Amaç, Jenkins'in en kısa sürede Yeşil'e gitmesini sağlamaktır, böylece en kısa zamanda doğru yönde hareket etmeye başlayabilirsiniz.

Testleri alakalı tutun.

Kod eklerken veya değiştirirken yeni testler eklemek için çözün ve geçen tüm testleri geçmeyi taahhüt edin.

Testler, başlangıçta iyi yazılmış testler olmadığı gerçeği dahil olmak üzere çeşitli nedenlerle başarısız olabilir. Ama Jenkins bir kez yeşile döndüğünde, onu böyle tutmak gerçekten önemli.

İyi sınamalar yazmaya alışın ve sınamalar başarısız olursa büyük bir anlaşma yapın.

Her test için amacı belirleyin.

Engelli testlerini birer birer yapınız. En sık değiştirdiğiniz modülleri etkileyenlerle başlayın. Testin amacını ve başarısızlığın nedenini belirleyin.

• Bilerek kod tabanından çıkarılmış olan bir özelliği test ediyor mu? O zaman muhtemelen silebilirsiniz.

• Henüz kimsenin farketmediği bir hatayı mı yakalamak? Testi tekrar yapın ve hatayı düzeltin.

• Hatalı varsayımlarda bulunduğundan başarısız oluyor mu (örneğin, düğme metninin her zaman İngilizce olacağını varsayıyorsunuz, ancak şimdi birden fazla dilde başvurunuzu yerelleştirdiniz)? Ardından testin tek bir şeye odaklanmasını sağlayın ve ilgisiz değişikliklerden olabildiğince izole edin.

• Test tüm uygulama boyunca yayıldı mı ve bir Sistem testini temsil ediyor mu? Ardından ana Jenkins test takımınızdan çıkarın ve daha az çalışan Regression odasına ekleyin.

• Uygulamanın mimarisi tanınmayacak kadar değişti mi, bu nedenle test artık yararlı bir şey yapmıyor mu? Silin.

• Test kod kapsamı istatistiklerini yapay olarak artırmak için eklendi mi, ancak gerçekte kodun doğru bir şekilde derlendiğini ve sonsuz bir döngüye girmediğini doğrulamaktan başka bir şey yapmıyor mu? Ya da, test sadece seçtiğiniz alaycı çerçevenin az önce söylediğiniz sonuçları verdiğini onaylar. Silin.

Bunun bir sonucu olarak, bazı testler duracak, bazıları değiştirilmiş, bazıları çoklu bağımsız, ısırık büyüklüğünde parçalara ayrılmış, bazıları ise kaldırılmış. Halen yeni gereksinimler konusunda ilerleme kaydettiğiniz sürece, bunun gibi teknik borçlarla başa çıkmak için biraz zaman ayırmak, yapılması gereken şeydir.

4000 test zor bir problemdir. 40 test daha izlenebilirdir. Çalıştırmak ve analiz etmek için rastgele yönetilebilir sayıda test seçin. Sonuçları şöyle sınıflandırın:

1. Yararsız test
2. Temiz çalışan faydalı test
3. Başarısız olan faydalı test

Testlerin çoğu birinci kategoriye girerse, mevcut test takımınızı atmanız ve mevcut kod için faydalı bir deneme hazırlamanın zamanı olabilir.

Testlerin birçoğu size kodunuzdaki bir sorundan bahsedecek şekilde başarısız oluyorsa, sorunları gidermek için yapılan başarısızlık testleriyle çalışmanız gerekir. Bir veya iki hatanın düzeltilmesinin çok sayıda test yapılmasını sağladığını görebilirsiniz.

Bu ifade doğruysa,

Testler ... her büyük kod değişikliğinde deli gibi başarısız oluyor.

bu, "daha büyük bir kod değişikliğinden" hemen önce koda geri dönmeniz durumunda, testlerin çoğunun tekrar geçeceği anlamına gelir. Bunu yaptıktan sonra, daha küçük bir değişiklik yığını kapın ve hangi testlerin yeni başarısız olduğunu görün. Bu, hangi kod değişikliklerinin hangi testlerin başarısız olmasına neden olduğunu daha iyi izole etmenize yardımcı olur. Her test için, sorunu izole ettikten sonra, yeni kodun hatalı olup olmadığını veya testin hatalı olup olmadığını belirleyebilmelisiniz. Yeni kodla ilgili bir sorun varsa, belirli bir hatanın giderilmiş olması durumunda, en son sürümle karşılaştırdığınızdan emin olun.

En son kod tabanını alana kadar tekrarlayın.

Bu ezici bir görev gibi görünebilir, ancak bu yoldan aşağıya inip bazı problemleri izole etmeye başladığınızda, süreci büyük ölçüde hızlandıracak bir model ortaya çıkmaya başlar. Örneğin:

• Birçok testin kusurlu olan başka bir şeye bağlı olduğunu fark edebilirsiniz. Bir parçanın düzeltilmesi birçok testi düzeltebilir.
• Birçok testin hatalı olduğunu ve düzeltilmesi veya kaldırılması gerektiğini fark edebilirsiniz.
• Belirli bir geliştiricinin testlerin bozulmasına neden olma sıklığının daha yüksek olduğunu fark edebilirsiniz. Bu geliştiricinin daha fazla eğitim veya denetime ihtiyacı olabilir.

Ne test ettiklerini bilmiyorsanız, öğrenene kadar bunları kaldırın. Testler akışkan şeylerdir, artık gerekmeyen bir özelliği kaldırırsanız, o özelliği test eden testi değiştirmek zorundasınız! Bu nedenle, testlerin ne test ettiğini bilmiyorsanız, kod üssünü yerinde değiştirmek için hiçbir ümitiniz yoktur.

Test sisteminin geliştiricisinin makinelerinde kurulumunu yapabilir ve orada çalışarak testlerin hangi parçalarla etkileşime girdiğini görebilir, umarım bu eksik belgeleri sağlayabilir ve kod tabanını doğru şekilde değiştirmeyeceğiniz konusunda daha aşina olabilirsiniz. doğru test daha uzun.

Kısacası - değişiklik yaptığınızda eski testleriniz başarısız oluyorsa, kod değişiklikleriniz iyi değildir. Bu testleri sistemin nasıl çalıştığını bir eğitim aracı olarak kullanın.

Yapacağım en önemli şey, hangi testlerin yapılması gerektiği ve işin devam etmesi için gerekenlerin temellerine geri dönmektir. Testin işi, sorunları daha sonra çözülmeleri için pahalı hale gelmeden önce belirlemektir. Bence bu cümlede anahtar kelime "pahalı" dır. Bu sorunların bir iş çözümüne ihtiyacı var. Alanda pahalı konular ortaya çıkıyor mu? Öyleyse, test tamamen başarısız oluyor.

Yönetiminiz ve bir gerçeklik kontrolüne gelmeniz gerekiyor. Eski bir dizi testten dolayı geliştirme maliyetlerinin hızla yükseldiğini görüyorsunuz. Testler devre dışı bırakıldığından, bu maliyetler hatalı bir ürünü teslim etmenin maliyetleriyle nasıl karşılaştırılır? Kullanıcıların hangi davranışlara ihtiyaç duyduğunu (test edilmesi gerekenler hangileri) bulmanın zorlu görevini nasıl karşılaştırırlar?

Bunlar, iş çözümlerine ihtiyaç duydukları konulardır çünkü işin iş tarafına dokunurlar. Bir müşteriye ürün gönderiyorsunuz ve bu, işin çok ilgilendiği bir sınırdır. Bir geliştirici olarak sizin yapamayacağınız çözümleri tanımlayabilirler. Örneğin, iki ürün sağlamaları makul olabilir: güvenilirliğe ihtiyacı olan ve daha fazla hataya sahip olan ancak öncü olan bir "vizyon sahibi" ürünle, yeni özelliklerden istekli olanlar için bir "eski" ürün. Bu size iki bağımsız test seti geliştirme fırsatı verir ... biri bir tane 4000 testi, bir tane de yapılması gerektiğini düşündüğünüz testlerden biri (ve bu işlemi tekrarlamamalarını belgeleyin).

Sonra sanat başlar: bu iki başlı canavarı nasıl yönetirsiniz, böylece bir daldaki ilerlemeler diğer dalda da yardımcı olur? "Visonary" şubesine yaptığınız güncellemeler, katı test gerekliliklerine rağmen, "eski" şubeye nasıl geri dönebilir? "Eski" şubeden devam eden müşteri istekleri, ürünleri eninde sonunda yeniden birleştirdiyseniz, eski müşterilerinizin ihtiyaç duyacağı gereksinimleri anlama şeklinizi daha iyi nasıl şekillendirebilir?

Eski testleri kaldıramadık çünkü ne test ettiklerini bilmiyorduk!

İşte bu yüzden eski testleri kaldırmalısın! Ne yaptıklarını bilmiyorsanız, o zaman başarısızlık anlamsızdır ve onları çalıştırmak zaman kaybıdır. Onları dışarı at ve baştan başla.