Cevap.

Otomatik testlerin otomasyonu, başlangıçta hız artırma ve insan faktörünü azaltma fikirleriyle başlamıştı, ancak çok geçmeden otomatik testlerin her çalıştırmada farklı davrandığı ortaya çıktı. Tekrarlanabilirlik (repeatability) ve belirlenebilirlik (determinism), otomasyon testlerinin kalitesi için temel gereksinimlerden biridir ve aynı koşullar altında aynı sonucu vermelidir.

Problemler, görünmeyen bağımlılıklar nedeniyle başlar: kararsız test verileri, senkronize edilmemiş ortamlar, paralel süreçler veya üçüncü taraf hizmetler. Bu, tahmin edilemeyen sonuçlar veren flaky testlere yol açar.

Çözümler, çalışma ortamının sıkı kontrolü, testlerin izolasyonu, mock/stub nesneleri, statik veriler ve tekrar edilebilir senaryolar etrafında inşa edilir (örneğin, her testten önce veritabanının temizlenmesi ve hazırlanması).

Anahtar özellikler:

Test verilerinin kontrolü ve test ortamının öngörülebilir bir şekilde başlatılması.
Testlerin birbirinden izole edilmesi ve testler arası bağımlılıklardan vazgeçilmesi.
Kararsız veya dış hizmetlerle çalışmak için Mock/Stub nesnelerin kullanılması.

Kandırmaca Sorular.

Eğer flaky test yalnızca CI'de meydana geliyorsa, yerel ortamda her şey stabil, ne yapmalıyız?

Bu çoğu zaman çevrelerdeki farklılıklarla ilgilidir: bağımlılıkların sürümleri, altyapının çalışma hızı, paralellik, işletim sistemi ayarları veya testlerin çalıştırılma sırası. Çözüm — CI ortamını geliştirici bilgisayarına (Docker, aynı seed değerleri, testlerde setUp/tearDown yapılandırması) mümkün olduğunca yakın hale getirmektir.

Veriler veritabanından alındığında, parametreli testler tam olarak belirlenebilir sayılır mı?

Hayır. Veriler temelde aynı olsa bile, veritabanı testler veya sürümler arasında değişebilir. Gerçek belirlenebilirlik için veriler her testte açıkça hazırlanmalı ve temizlenmelidir.

Ögelerin yüklenmesini beklemek için sleep kullanmak, UI testlerinin kararsızlık problemini çözer mi?

Hayır. Sleep sadece problemi maskelemektedir ve testlerin çalıştırılmasını yavaşlatır. Doğru bir şekilde, belirli koşulları bekleyen açık beklemeler (Explicit Waits) kullanılmalıdır, sabit bir zaman değil.

Tipik Hatalar ve Anti-Desenler

Doğru senkronizasyon yerine "sihirli" sayılar ve gecikmeler kullanmak.
Testler arası bağımlılık veya testler arasında geri alınamayan ortam durumu değiştirmek.
Senaryolar arasında test verilerinin karışması.

Gerçek Hayattan Bir Örnek

Olumsuz Durum

Projede, kimsenin manuel testlerden sonra temizlemediği bir ortamda UI testleri çalıştırılıyordu. Her birkaç gecede bir, testler yerel olarak olmayan "rastgele" hatalarla çöküyordu. Ekip, testlerde sleep ekledi ve flaky problemlerini görmezden geldi.

Artılar:

Problemin kök nedenini çözmek için fazla zaman harcamak zorunda kalmadı.
Testler bazen yine de hataları bulmayı sağladı.

Eksiler:

Yeniden çalıştırmalara zaman harcama.
Yanlış negatif sonuçlar mühendisleri demotive etti.
Raporlar gürültü ile kaplandı, gerçek regresyon kaçırılabilir.

Olumlu Durum

Olgun bir DevOps mühendisi ortaya çıktıktan sonra ekip, test verilerini sıfırlamak ve başlatmak için komut dosyaları uyguladı, kararsız entegrasyonlar için mock servisler ekledi ve testleri konteynerlerde çalıştırmaya başladı. Flaky testler neredeyse ortadan kalktı.