Cevap.

Testin tekrar mekanizması (retry), test pipeline'ının kararlılığını artırmak ve flakey otomatik testlerle mücadele etmek amacıyla uygulanır, ancak akıllıca bir yaklaşım gerektirir.

Konu Tarihi Geçici altyapı veya flakey hatalarla başa çıkmak için bir çözüm olarak ortaya çıktı, uygulama hatalarıyla ilişkili değildir (istikrarsız ortam, ağ sorunları, rastgele API zaman aşım süreleri). Birçok CI/CD sistemi şimdi yerleşik retry desteği sunmaktadır.

Sorun Aşırı veya kontrolsüz retry gerçek hataları gizleyebilir veya çöküşleri "sadece geçici olaylar" haline getirebilir. Yanlış pozitif sonuçlar ortaya çıkar: testin geçtiği görünse de hata hala vardır.

Çözüm Sadece istikrarsız veya dışa bağımlı testler için retry uygulayın, etiketler veya işaretler kullanın. Tekrarlamalar için sabit bir limit belirleyin (1-2 kez). Tüm çöküşlerin ve yeniden çalıştırmaların başarılarını kaydedin, böylece hataların nedenlerini analiz edebilirsiniz.

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # API'nin istikrarsızlığı nedeniyle başarısız olabilecek bir test
    ...

Ana özellikler:

Noktasal ve bilinçli uygulayın
Daima tekrarların nedenlerini analiz edin
Uygulama hatalarını maskelemeyin, yalnızca altyapı/flaky sorunlarını ele alın

Şüpheli Sorular.

Pipeline'daki tüm otomatik testlerin tekrar başlatılması mümkün mü?

Bu kötü bir uygulamadır: hem gerçek hataları hem de testlerin mimari sorunlarını gizler. Retry bazı test türleri için son çare olmalıdır.

Eğer 3 tekrar denemesinden sonra test hala geçmiyorsa ne yapmalıyız?

Başlatmayı durdurun ve istikrarsızlık/bir inceleme için bir hata kaydı açın — böylece yeniden yapılandırma gerektiren tricky hataları ortaya çıkarabilirsiniz.

Eğer test ikinci seferde geçiyorsa, bu iyi bir şey mi?

Hayır, tek doğru durum — ilk seferde kararlı bir geçiştir. İkinci seferde geçiş, bir sorunun göstergesi (flakey veya altyapı) olarak kabul edilir.

Tipik Hatalar ve Anti-Desenler

Kontrolsüz retry uygulaması, hataları gizliyor
Çöküş nedenleri için analitiğin olmaması
Gerçek sorunların çözümü yerine retry kullanımı

Gerçek Hayat Örneği

Olumsuz Durum

Jenkins pipeline'ının tamamı için iki deneme ile küresel retry etkinleştirildi. Bir ay sonra, koddaki race condition nedeniyle hatalar yayılmaya başladı ve ekip "kalite tamam" olduğunu düşündü. Ürün, bu hatalar nedeniyle üretimde aniden çökme yaşadı.

Artılar:

Yeşil pipeline'lar vardı

Eksiler:

Uygulama hataları zamanında tespit edilmedi
Kaynağın güvenilmezliğini anlamak zorlaştı

Olumlu Durum

Dış API'lere sahip test kategorisi için sadece onlara retry ayarlandı (etiketler üzerinden). Diğer tüm testler kesinlikle tek bir çalıştırma ile geçiyor. Ekip, kayıtlarda tekrar eden başarısızlıkları araştırıp kaydediyor.