Kod Gözden Geçirme Pratikleri (What to Look For in a Code Review) — Part 2: Testler
Merhaba, kod gözden geçirme yazı serimin bu bölümünde testlerden bahsedeceğim. Kod gözden geçirme ile test arasında nasıl bir ilişki olabilir sorusunu kendimce yanıtlamaya çalışacağım.
Normal bir yazılım geliştirme yaşam döngüsünde automated testler yazılır, PR istekleri ile beraber CI/CD sırasında testler çalışır ve olası bir hata durumunda tüm süreç iptal edilir. Bu nedenle test yazımı ve dolaylı yoldan doğru test yazımı kodumuz için en önemli ve hata önleyici pratiklerden birisidir diyebiliriz.
Kod gözden geçirme sırasında gelen PR isteğindeki test durumları için aşağıdaki gibi benzer soruları yanıtlamaya çalışarak süreci başarılı bir şekilde yönetebiliriz. Bu sorular;
- PR isteği ile iletilen kayıtta eklenmiş yeni kod bloklarını ve/veya değiştirilen kod bloklarını kapsayacak şekilde uygun testler yazılmış ve dahil edilmiş mi? Mantıklı olan her yeni kod veya değişiklik için bunu kapsayacak şekilde test durumlarını yazmaktır, eğer PR isteğindeki maddeler için uygun test yazılmamış ise neden yazılmadığını sormamız faydalı olacaktır.
- Yazılmış olan testler gerçekten kodumuzdaki en önemli değişikliğin sonucunu mu test ediyor yoksa happy path dahilinde görece basit ve hata riski minimum olan yeri mi kapsıyor? Çünkü hiç test olmaması ile kodumuzun en önemli ve riskli olabilecek yeri kapsayacak test yazılmaması da benzer olarak değerlendirilmelidir. Çoğumuzun şirketinde CI/CD süreçlerinde build sırasında “test coverage” oranına göre build success/fail kararı verilmektedir ve build’in başarılı sonuçlanması için gereksiz veya basit olan yerlere test yazmak daha kolay olduğundan ilk tercih olarak bu yöntemle ilerleyip coverage yüzdemizi artırmayı hedeflemekteyiz, bu da bize gösteriyor ki yüzdenin yüksek olması kodumuzdaki önemli yerlerin testler kapsamına alınıp alınmadığı konusunda bilgi vermiyor. Riski minimize etmek için kod gözden geçirme sırasında bu sorunun sorulması kritik bir önem arz ediyor.
- Testleri kod gözden geçirme task’ını üzerine alan birisi olarak siz de anlayabiliyor musunuz? Testlerin kodumuzun her yerini kapsaması bir tarafa anlaşılır olması da ayrıca önemlidir. Mesela testlerden birisi fail olduğunda neden fail olduğuna dair algıyı hemen anlayabilir miyiz veya hata durumunda basitçe düzeltebilir miyiz gibi durumlar testleri anlayabilmekten geçiyor. Okunabilirlik, anlamlı isimlendirme gibi kurallar yazdığımız testler için de geçerli olmalıdır.
- Yazılan testler gerçekten de gereksinimlerimize uygun yazılmış mı? Bu sorunun cevabını tamamen insan gözüyle vermemiz gerekiyor çünkü henüz herhangi bir automation tool’un gereksinimleri anlayıp onu kontrol etmesi şu an yaygın bir pratik değil. İncelenen kod tarafından karşılanan gereksinimler ister sdlc dokumanlarında belirtilmiş olsun, ister bir user story’de, isterse de bir kullanıcı tarafından oluşturulan bir hatada yer alıyor olsun, gözden geçirilen kod bazı ilk gereksinimlerle ilgili olmalıdır ve onları kapsamalıdır. Gözden geçirmeyi yapan kişi olarak testler ister birim, ister uçtan uca veya başka bir şey olsun, gereksinimlerin kesinlikle karşılandığından emin olunmalıdır..
- Yazılan testlerin kapsamadığı bir senaryo düşünebiliyor muyum? Bu sorunun amacı gereksinimlerin net olmadığı durumlarda yazmış olduğumuz testlerin tüm “edge case” dahil senaryoları kapsayıp kapsamadığını öğrenmeye çalışmaktır. Örnek verecek olursak, bir login sistemi için yeni kod yazdığımızı ve başarılı/başarısız senaryolar için kodumuzu implement ettiğimizi düşünelim. Burada input validation, kimlik doğrulama, exception handling gibi bir çok durum meydana gelebilir. Bu durumda kodumuz ve yazılan testler tüm bu durumları kapsıyor mu sorusuna yanıt vermek önemlidir.
- Testler doğru seviyede mi yazılmış? Buradaki seviye test piramidindeki seviyeyeleri belirtmektedir. Bu piramide göre testlerimizin maliyeti aşağıdan yukarıya gittikçe artmaktadır. Bu nedenle sadece unit test yazarak çözebileceğimiz bir sorunu integration veya ui test yazarak test ediyorsak bu doğru bir yöntem olmayacaktır.
- Güvenlik senaryolarını kapsayan test yazılmış mı? Kodumuzda güvenlik, authorization ve authentication ile alakalı bir durum yazılmışsa, örneğin kullanıcı doğrulaması yapılmadan herhangi bir business işlem yapmaya yetki verilmemesi gerekiyor gibi senaryolar test edilmelidir.
Test yazımı, yazılım kalitesi ve hata önleme için çok önemli bir madde olup sorumluluk sadece kodu yazan kişide değildir. Kod gözden geçirme sorumluluğunu alan kişi için de aynı derecede önemli olup gerekmesi durumunda yeni test senaryoları yazma işini de gözden geçiren kişinin yapması beklenen bir durumdur. Sonuç olarak test kültürü olası problemleri canlı ortamda henüz ortaya çıkmadan engellemenin en kolay ve basit yolu olup görece az maliyetli bir yaklaşımdır. Yazılım yaşam döngümüzde test yazımını desteklemeli ve bu kültürü yaygınlaştırmak için çalışmalar yapmalıyız.
Kod gözden geçirme — test yazımın sonuna geldik. Vakit ayırıp okuduğunuz için teşekkür ederim. Başka yazılarımda görüşmek üzere…
