Cevap.

Legacy kodun test edilmesi otomatikleştirilmesi, BT alanındaki en büyük klasik sorunlardan biridir.

Sorunun tarihi: Birçok şirket, gelecekte otomatikleştirmenin dikkate alınmadığı sistemleri test etme gerekliliği ile karşılaşır. Bu tür projelerin genellikle zayıf belgeleri, yüksek teknik borçları ve izole bileşen eksiklikleri vardır.

Sorun: Ana zorluklar şunlardan kaynaklanır:

Test kancalarının ve entegrasyon noktalarının olmaması
Test etme için verilerin izole edilmesi imkansızlığı
Modüller arasındaki güçlü bağımlılık
Kodda yansıtılmamış birçok anomali ve değişiklik.

Çözüm: Genellikle süreç adım adım ilerler:

Sistem analizi: kritik iş süreçlerini belirlemek ve otomatik testler için kapsam alanını uyumlu hale getirmek gereklidir.
Test noktalarının uygulanması: Mümkünse kodun bir kısmı proxy'lere sarılır, test çiftlerine uyumlu hale getirilir veya bağımlılık enjeksiyonu kalıbı kullanılır.
Adım adım otomatik testlerle kaplama: Öncelikle "en basit" ve en az bağlı kod için testler yazılır.
Sürekli destek ve yeniden yapılandırma: Testler eklendikten sonra, iyileştirmeler için güvenlik ağı olarak kullanılır.

Anahtar özellikler:

Testler genellikle sıfırdan yazılmadığı gibi, mevcut fonksiyonların "sarılması" ile başlar.
Test edilebilirliği mimariye aşamalı olarak eklemek gerekir.
İş dünyasının kritik senaryoların düzenlenmesine en üst düzeyde dahil olması gerekmektedir.

Kandırma soruları.

Legacy kodun tamamen yeniden yapılandırılmasından önce otomatik testler yazmaya başlayabilir miyiz?

Evet, genellikle otomatik testlerin tam olarak bu süreçte yeniden yapılandırmayı güvence altına almak için gerekli olduğu söylenebilir. Tam "mükemmellik" beklememek gerekir; aksine, testler cesur değişiklikler yapmayı sağlayabilir.

Tüm legacy kodu otomatik testlerle kaplamaya çalışmalı mıyız?

Hayır. En riskli ve sık kullanılan senaryolar üzerinde yoğunlaşmak gerekir. "Her şeyi kaplama" hızı olumsuz etkiler ve anlam kazanmaz.

Legacy kodu test etmek için modern kalıpları (DI gibi) uygulamak zorunlu mu?

Hayır, ancak kaynaklar izin veriyorsa bunların kullanılması önerilir. İlk adım, en azından kısmi izolasyondur; mocklar ve kodda özel test noktaları.

Tipik hatalar ve anti-kalıplar

Tüm kodun bir anda otomatik testlere geçirilmesi — projeler durur ve iş anlamı kaybolur.
Önemsiz fonksiyonların "paranoid" şekilde kaplanması.
Geliştirme, test etme ve iş dünyası arasında iletişim eksikliği.

Hayattan örnek

Olumsuz vaka

Ekip, tüm eski uygulamayı SOLID kalıplarına göre yeniden yazmaya çalışarak %100 kod kapsamaya çalıştılar.

Artılar:

Mimari temel bir iyileşme.
Uzun vadede testlerin fayda sağlayabileceği düşüncesi.

Eksiler:

Bazı aylar boyunca geliştirme süresi durdu.
Sürekli hatalar ve iş talepleri ile senkronizasyonda problemler.
Testlerin yazıldığı zaman, kodun geçerliliğinin kaybolması.

Olumlu vaka

Otomatik testler sadece hesaplama için kritik noktalarda, genel kodu minimum değiştirerek, özel stabilizasyonlar uygulayarak hayata geçirilmiştir.