Cevap.

Konunun geçmişi:

Başlangıçta otomatik testler genellikle "doğrudan" yazılıyor, mimari ayrımlar olmadan: kontrol mantığı ve yürütme mekanizmaları karışıyordu. Projelerin büyümesiyle, çerçeve ile test mantığının karışmasının kırılgan, bakımı zor bir kod tabanı yarattığı açıktı. Sorumlulukların ayrılması konusunda mimari öneriler ortaya çıktı.

Sorun:

Testler, çerçevenin içsel uygulamalarına bağlıysa veya çevre ile etkileşim mantığı içeriyorsa, herhangi bir değişim çok sayıda testin yeniden yazılmasını zorunlu kılar. Test senaryoları karmaşık hale geliyor, kod tekrar ediliyor, yeni bir çerçeveye veya platforma geçiş zorlaşıyor.

Çözüm:

Sıkı bir şekilde ayırın:

Çerçeve (baseline infrastructure): testlerin başlatılması için genel mekanizma, günlükleme, hata işleme, raporlar, yardımcı sınıflar için bir temel (örneğin, sürücüler, adaptörler ve yardımcı araçlar).
Test mantığı (test cases): testin anlamlı amacını ifade eden belirli senaryolar, yalnızca çerçevenin kamuya açık API'lerini kullanır.

Temel özellikler:

Platform değişimlerinin izolasyonu sayesinde bakım kolaylığı
Test mantığının yeniden kullanılabilirliği
Kodun fazlalığı ve tekrarının azaltılması

Kandırmaca Sorular.

Testlerde çok sayıda adım varsa doğrudan yazmak mümkün mü?

Bunu yapmamalısınız. Kısa testler bile büyüyebilir ve katman eksikliği hızla karmaşaya yol açabilir.

Test senaryoları başlatma mekanizmasından haberdar olmalı mı (örneğin, sürücüyü ne zaman başlatacaklarını bilmeliler)?

Hayır. Tüm altyapı detayları çerçeve katmanında gizlenmelidir.

Testlerin parametrelerini (örneğin, url, kimlik bilgileri) testler içinde sabitlemek normal midir?

Hayır. Test parametreleri, çerçeve ve çevre ayarları aracılığıyla yapılandırılmalıdır.

Tipik Hatalar ve Antipatternler

Çerçevenin içinde değil, testlerin içinde durum kontrolü yapma
Testlerde çerçeveye ait özel yöntemleri kullanma
Testlerde yardımcı fonksiyonların tekrar edilmesi
Parametreleri sabitleme

Gerçek Hayattan Bir Örnek

Negatif Durum

Projede testler doğrudan Selenium sürücüsünün yöntemlerini çağırıyor, her testte WebDriver'a bağlantı tekrar ediliyor. Her test, konfigürasyonu ayrı ayrı parseliyor.

Artıları:

Mimari olmadan hızlı bir şekilde otomatik test yazmaya başlanabilir.

Eksileri:

Sürücünün veya başlatma parametrelerinin değiştirilmesi, kitlesel düzenlemelere yol açıyor
Tüm testlerde tekrarlayan kod
Projeyi ölçeklendirmek ve bakımını yapmak zor.

Pozitif Durum

Testler çerçevenin temel soyutlamalarını kullanıyor: ortak başlatma ve teardown, yapılandırıcı aracılığıyla parametrelerin geçişi, test mantığı yüksek seviyeli yöntemler aracılığıyla ifade ediliyor.