Bir CI hattına görsel test eklemek, çoğu ekipte iki haftalık bir iş değil görünüyor. YAML dosyası yazılır, ekran görüntüsü alınır, karşılaştırma yapılır. Asıl zor olan kısım bundan sonrasıdır ve YAML'da değildir.
Bu yazı, teknik adımları değil karar adımlarını anlatıyor. Çünkü bir görsel hattı, neyi karşılaştıracağınıza ve kırılmayı kim onaylayacağınıza karar vermeden kurulamaz.
Önce: bu hatta mı girmeli?
Görsel testin CI hattında olması her projede gerekli değildir. Karar şu soruya bağlıdır: kırılma yayına girmeden önce mi yakalanmalı?
- Evet → CI hattında olmalı. Geliştirme ortamında, yayın öncesi.
- Hayır → Canlı izleme yeterlidir. Yayınlandıktan sonra fark edilir.
Ayırım önemli, çünkü ikisi farklı problemlerdir:
CI'daki görsel test bir kabul testidir. "Bu değişiklik kasıtlı mı?" sorusuna cevap verir. Geliştirici karar verir.
Canlı izleme bir tespit aracıdır. "Canlıda ne değişti?" sorusuna cevap verir. Kimse karar vermez, sadece olur.
Bu yazı CI tarafına odaklanıyor. Canlı taraf için çoklu müşteri izleme yazısına bakın.
Adım 1: Neyi karşılaştıracağınıza karar verin
Bu, tüm işi belirleyen karardır. Ve çoğu ekip bunu atlar.
Üç seçenek var:
1. Tüm sayfalar. En kapsamlısı, en pahalısı, en gürültülüsü. Çoğu proje için fazla.
2. Kritik sayfalar. Giriş, ana sayfa, ödeme, kayıt. Az sayıda, yüksek değerli. Çoğu proje için doğrusu budur.
3. Bir bileşen kütüphanesi. Sayfa değil, bileşen. En hızlısı, en az kırılgan olan. Bileşen kütüphanesi olan ekipler için doğru yer burasıdır.
Pratik kural: on sayfadan başlayın. Altı ay sonra sayıyı artırın. Baştan yüz sayfa seçmek, hattı kullanılamaz hâle getirir ve ekipler testi devre dışı bırakır.
Adım 2: Karşılaştırma neye karşı yapılacak?
Bu da atlanan ikinci karardır.
Seçenek A: Depodaki referans görüntü. Her sayfanın "doğru" hâli depoda tutulur. Değişiklik olduğunda, depodaki görüntüyle karşılaştırılır.
Avantajı: belirleyici. Dezavantajı: referansı güncellemek gerekir ve bu güncelleme sizin kararınız olmalıdır.
Seçenek B: Ana dalın görüntüsü. PR'daki değişiklik, ana dalın görüntüsüyle karşılaştırılır.
Avantajı: referans güncel kalır. Dezavantajı: ana dal zaten bozuksa, PR da yanlış görünür.
Seçenek C: Bir önceki dağıtımın görüntüsü. Canlıdaki son sürümle karşılaştırılır.
Avantajı: gerçekle ne karşılaştırdığınız nettir. Dezavantajı: canlıda varsa sistem geriye doğru da çalışır.
Çoğu ekipler A ile başlar, sonra B'ye geçer. A'nın en büyük avantajı, referansın kasıtlı tutulmasıdır: kim güncelliyorsa, değişikliği onayladığını da onaylamış olur.
Adım 3: Kırılma kim onaylar?
En çok atlanan ve en pahalı adımdır.
Görsel test kırıldığında iki yol vardır: kırılma gerçekse düzeltilir, değilse görüntü güncellenir. Bu ikinci işlem bilinçli bir onay gerektirir, çünkü görüntüyü güncellemek, kırılmanın nedenini kabul etmektir.
Bunu otomatikleştirirseniz, görüntü güncellemesi bir tuşa basılır hâle gelir ve sistem, kırılmaları doğrulamayan bir gözleme indirgenir.
Pratik kural: görüntü güncellemesi, kod değişikliğiyle aynı incelemeyi almalı. Aynı PR'da olmalı. İncelemesiz güncellenen görüntü, kanıt değildir.
Adım 4: Maskeleme kararlarını sürdürün
Bunu ayrı bir yazıda ele aldım: dinamik içerikte yanlış alarm. Burada hatta özel bir nokta var:
Maske kararı kodla birlikte sürümlenmeli. Maskeyi elle ayarlamak, hattı her gün elle bozmak demektir. Yeni bir sayfa eklendiğinde maskesi de eklenmelidir.
Bunun için en pratik yol, maskeyi sayfanın kendi tanımının yanına koymaktır — test kodunun içinde, ayrı bir yapılandırma dosyasında değil.
Adım 5: Sık yapılan dört hata
1. Her şeyi karşılaştırmak. Kapsam genişletildikçe gürültü artar, ekipler testi kapatır. Kapsamı dar tutmak, kapsamı genişletmekten daha iyidir.
2. Eşiği baştan ayarlamamak. İlk hafta alınan gürültüye bakıp eşiği ayarlamadan bırakmak. Eşik, sistemin ne ürettiğini bir hafta gördükten sonra belirlenir. Bu, alarm yorgunluğunun en sık görülen hatasıdır.
3. Görüntü güncellemesini otomatikleştirmek. Yukarıda anlatıldı.
4. Hatta ekleyip üretime almamak. Test, kimse bakmadığı sürece yavaşlar. Bir hattın işe yaraması, kaçırılan bir kırılmayla ölçülür. Altı ayda kaç kırılma yakalandıysa, o kadar işe yaramıştır.
Hattın yavaşladığı söylenirse
Görsel test, doğal olarak hattı yavaşlatır. Ekran görüntüsü almak zaman alır ve tarayıcı başlatır.
Üç seçenek var:
- Yalnız PR'da çalıştırın. Ana dala birleşimde değil. En sık tercih edilen.
- Sadece etiketlenen sayfaları çalıştırın. Değişen sayfayı etiketleyin, yalnız onu karşılaştırın.
- Paralel çalıştırın. Test işlerini eş zamanlı başlatın.
Hız için ilk adım, kapsamı daraltmaktır. İkinci adım paralellik. Üçüncüsü donanım.
Özet
- Görsel test bir YAML dosyası değil, karar mekanizmasıdır.
- Üç karar önce verilir: ne karşılaştırılacak, neye karşı, kırılmayı kim onaylayacak.
- Görüntü güncellemesi incelenmelidir; otomatikleştirilirse kanıt değerini yitirir.
- Kapsamı dar tutmak, gürültüyü azaltmanın en etkili yoludur.
- Hattın işe yaradığını, kaçırılan kırılma sayısı ölçer.
Karşılaştırmanın temelleri için görsel regresyon testi nedir? yazısı, hat dışındaki taraf için aracı seçerken bakılacak yedi şey yazısı.