Cevap.

Otomatik testlerle çalışırken doğru yapı, etkinlikleri ve sürdürülebilirlikleri için gereklidir.

Sorunun Tarihi

Daha önce otomatik testler genellikle monolitik ve birbirine sıkı sıkıya bağlı betikler olarak oluşturuluyordu. Bu, onların bakımını ve genişletilmesini zorlaştırıyordu. Test sayısındaki artış, iyi bir mimarinin önemini ortaya koydu.

Sorun

Açık bir yapı olmadan şunlarla karşılaşılır:

kodun tekrarı
gereksinimler değiştiğinde bakım zorlukları
düşük okunabilirlik ve yüksek hata olasılığı

Çözüm

Testleriniz için net soyutlama düzeyleri kullanın:

Test senaryoları, uygulama detaylarını değil, zaten uygulanmış adımları ve iş yöntemlerini çağırmalıdır.
İş seviyesi, teknik detayları açığa çıkarmadan kullanıcı eylemlerini (örneğin, "sipariş oluştur") kapsar.
Teknik seviye (örneğin, Page Object), UI veya API öğeleriyle çalışır.

İyi bir uygulama:

# Yapı örneği
/tests
  /features
    test_order_creation.py
  /steps
    order_steps.py
  /pages
    order_page.py

Ana Özellikler:

Sorumlulukların net ayrımı (katmanlar, modüller)
Maksimum kodun yeniden kullanılabilirliği
Değişikliklerin kolayca uygulanabilirliği (sadece bir varlığı değiştirmek yeterli)

Şaşırtıcı Sorular.

Daha iyi olan nedir: uzun end-to-end testleri mi yoksa kısa modüler otomatik testler mi yazmak?

Çoğu zaman yalnızca end-to-end tercih edilir, ancak hedeflere bağlı olarak farklı test türlerini birleştirmek önemlidir: tüm seviyeler (Birim, API, UI) kaliteli bir kontrol için önemlidir.

Testlerde UI kontrolünü hem metin hem de lokatörlerle aynı anda kullanmak mümkün mü?

Bu her zaman doğru değildir: her iki yöntemi aynı anda kullanmak mümkündür, ancak yalnızca UI'ın değişkenliği ve testin mantığı bunu haklı çıkarıyorsa. Genellikle gereksiz ve bakım zorluğu yaratır.

Otomatik testler oluştururken test edilen yazılım sisteminin yapısını tamamen kopyalamak gerekli mi?

Hayır, otomatik testlerin yapısı test etmeyi kolaylaştıracak şekilde olmalıdır, uygulamanın mimarisini tam olarak kopyalamak yerine.

Yaygın Hatalar ve Anti-Patternler

Test verilerini doğrudan testlerin içine hardcode etmek
Her testte aynı eylemleri kopyalamak
"Hepsi bir arada" betikleri: test, hemen birçok senaryoyu gerçekleştiriyor.

Gerçek Hayattan Bir Örnek

Olumsuz Senaryo

Bir ekipte otomatik testleri tek bir kişi yazıyordu, testler bir dosyada yer alıyordu, her test önceki adımları kopyalıyordu. Arayüz güncellendiğinde hatayı tüm testlerde manuel olarak düzeltmek gerekiyordu.

Artılar:

Temel testlerin hızlı yazımı

Eksiler:

İş mantığındaki değişiklikler, tüm testlerin yeniden işlenmesini gerektiriyordu, genellikle hatalarla birlikte.

Olumlu Senaryo

Başka bir ekip, mimari bir şablon (adım, sayfa, test ayrımı) getirdi. Yeni çalışanlar hızlı bir şekilde adapte oldu ve yeni testler hızlı bir şekilde entegre edildi, güncellemeler tek bir yerde yapıldı.