Test Otomasyonu Yazılım Geliştirmedir, Konfigürasyon Değil

"Daha fazla kapsama lazım" ile "sen bir otomatize ediver" arasında bir yerde sessiz bir varsayım sızar içeri: test otomasyonunun bir kurulum işi olduğu. Bir linter gibi bir kez ayarlayıp unuttuğun bir şey. Test paketlerini sessizce öldüren varsayım tam da budur.

Bir test paketi konfigürasyon değildir. İlk kod tabanına karşı çalışan ikinci bir kod tabanıdır. Bir mimarisi vardır, ya da yokluğu vardır. Tekrar (duplication), bağımlılık ve ölü kod biriktirir. Bileşik faizle büyüyen bir teknik borcu vardır. Tek seferlik bir konfigürasyon gibi davranırsan, tam da herkesin şikâyet ettiği o kırılgan ve güvenilmez yüke dönüşür; sonra da sanki sorun otomasyonmuş gibi suç "otomasyona" atılır.

Kodsa, Mimarisi Vardır

Yapısı olmayan production kodu bakımı imkânsız hale gelir ve bu kimseyi şaşırtmaz. Test kodu da farklı değildir. Her testin kendi seçicilerini (selector) sabit kodladığı, kendi verisini kurduğu ve kendi hazırlığını tekrarladığı bir paket, test paketi değildir; aynı hatanın üç yüz kopyasıdır. Production kodunu ayakta tutan ilkeler (sorumlulukların ayrılması, soyutlama katmanları, page-object ya da screenplay desenleri) burada da aynı güçle geçerlidir. Değişen bir locator iki yüz yerde değil, tek bir yerde güncellenmelidir.

Kodsa, İncelenmesi Gerekir

Bir kez yazılıp bir daha okunmayan bir test, kimsenin güvenmediği bir testtir. Test kodu, production koduyla aynı pull-request incelemesini hak eder: doğru şeyi mi doğruluyor, okunabilir mi, bir sonraki kişi bu testin neden var olduğunu anlayacak mı? Yanlış sebeple geçen bir test, hiç test olmamasından beterdir; çünkü sahte bir güven üretir. İnceleme, bunu canlıya çıkmadan yakalamanın yoludur.

Kodsa, Borç Taşır

Bir testteki her kısayol (koda gömülü bir bekleme, kopyala-yapıştır bir yardımcı, tam metne dayanan kırılgan bir doğrulama) bir kredidir. Bugün işe yarar, ondan sonraki her sprint'te faiz işletir. Hiç refaktör edilmeyen bir paket olduğu yerde durmaz; çürür ve on dakikalık bir özellik değişikliği iki günlük bir test tamir maratonunu tetikleyene kadar bozulur. Test kod tabanının planlı refaktörü bir ek yük değildir. Tüm yapıyı ödeme gücünde tutan bakımın ta kendisidir.

Bunun İma Ettiği Rol

Otomasyon bir yazılım geliştirme faaliyetiyse, onu yazan kişi de konfigürasyon dolduran bir araç operatörü değil, doğrulama konusunda uzmanlaşmış bir yazılım mühendisidir. Stack trace okur, değişime göre tasarlar ve kendi kodunun kalitesini sahiplenir. Serinin buradan sonra döneceği zanaat tam da budur.

O halde kendi paketine dürüstçe bak: bir daha hiç açmak zorunda kalmamayı umduğun bir şey gibi mi konfigüre edilmiş, yoksa saklamayı planladığın bir ürün gibi mi tasarlanmış?