CI/CD süreçlerinde Test Otomasyonu
Agile ile birlikte aslında test süreçleri kısaldığı için daha kısa zamanda daha etkin bir test süreci oluşturmamız gerekiyor. Agile yazılım yaşam döngüsünde, gereksinimlerin hazırlanma hızı ve bunlara ait geliştirmelerin de hızlanması ile birlikte, bu hıza test açısından da aynı şekilde yanıt vermek gerekmektedir. Aslında test, yazılım yaşam döngüsünden bağımsız gerçekleştirilen bir süreç değil, aksine döngünün her adımında işletilmesi gereken bir süreç. Bununla birlikte test otomasyonu otomasyon scriptleri yazıyoruz ancak elbette işimiz script yazmakla bitmiyor. Yukarıda söylediğim gibi bu hıza ayak uydurmamız gerekiyor. Yazılan scriptlerin CI/CD süreçlerine entegre ederek, continious testing kültürünü ekip ya da şirket içerisinde oluşturmamız gerekir. Böylelikle uygulama güncellemelerinin ve altyapı değişikliklerinin kalitesinden emin olarak hem daha hızlı daha güvenilir şekilde teslimat gerçekleştirilebilir. Bunun yanında da son kullanıcı deneyiminin olumlu kalmasını sağlayabiliriz.
Ben de bu yazımda sizlere test otomasyon süreçlerinin CI/CD hattına nasıl entegre edilebileceğinden bahsetmek istiyorum.
Yazıma CI/CD süreçlerine geçiş yapmadan önce Test Süreçleri için öne çıkan bir kültürden bahsederek başlayacağım.
Ideal Test Pyramid
Ideal Test Pyramid’i testleri kapsam ve boyutuna göre sınıflandırmak için kullanılır.
Bu patternden kısaca bahsetmek gerekirse;
Mike Cohn’un Succeeding with Agile adlı kitabında tasarlamış olduğu ideal test piramidinde gösterildiği gibi :
- Daha hızlı ve daha fazla izolasyona sahip olduğu için çok sayıda Unit Test yazılmalı. Unit Testler : Başka bir bağımlılık içermeden yapılabilmektedir.
- Low-Level’dır, sistemin küçük bir kısmına odaklanırlar. Böylelikle çok sıklıkla çalıştırılabilirler.
- Orta düzeyde izolasyona sahip olduğu ve çok hızlı olmadıkları için bazı servis testleri yazılmalı. Servis (API/Integration/Component) Testleri : Servis testleri, REST APIS ve veri tabanı gibi diğer sistemlerle entegre olan testlerdir.
- Daha yavaş oldukları ve daha fazla entegrasyona sahip oldukları için çok az UI Testi yazılmalı.
- Piramitte yukarı doğru çıkıldıkça Coverage, Maintenance, Fragility, Duration, Cost artmaktadır.
Biraz da Kod Kalitesinin Sağlanmasından bahsedelim
Continuous Code Quality Nedir?
Kod kalitesinin sürekli olarak denetim altında tutulması, projeye eklenen yeni kodlarda mevcut olabilecek bug, güvenlik zafiyeti, anti-pattern, gereksiz veya tekrarlı kod vb. gibi olumsuz durumların otomatik olarak gözlemlenmesi ve raporlanabilmesidir.
Continuous Code Quality’i Continuous Integration sürecine eklenebilen yan bir süreçtir. Yazımın konusu ise bu sürecin nasıl eklenebileceğidir.
DevOps kültürünün benimsendiği ve uygulandığı ekiplerde, bu kültürün bir sonucu olarak, işleri otomasyona bağlamaya olan eğilim, ekibi bir kod kalite analiz yazılımını CI hattı içerisine dahil etmeye yöneltmektedir.
Continuous Quality’i CI hattına dahil edilmesi ile yazılım deployment süreçlerinin hızlı, kararlı , performanslı, güvenli ve kaliteli bir şekilde gerçekleştirebilirsiniz.
Peki Continuous Quality süreçlerinde kullanabileceğimiz araçlar neler ve bunları hangi aşamada kullanmalıyız?
Static Code Analysis
Statik kod analizi, derlenebilir durumdaki bir uygulamanın kaynak kodları taranarak güvenlik zafiyetlerinin tespit edilmesidir.
Statik Kod Analizi, clean kod yazmanın en önemli bacağı olarak değerlendirilmelidir. Statik kod analiz araçları ile tekrarlı kodlardan kaçınma, kodlama standartlarına uyma, Unit Test’lerin yeterliliği, karmaşık kodların doğru bir şekilde tasarlanması gibi kriterleri karşılamak daha kolay olmaktadır.
Kullanılacak araç, uygulama geliştirirken kullandığınız programlama dili ve teknolojilere göre seçilmelidir. Bazı Statik Kod Analiz Araçları : SonarQube , CodeScene , Checkstyle , FindBugs , PMD, …
Nerede Kullanmalıyım?
Statik Kod Analizi’ni CI hattında uygulama build edildikten sonra, uygulama artifactleri çıkmadan önce çalıştırılmalıdır.
- Uygulama başarılı bir şekilde build olmalı.
- Build sonrası uygulama kodları belirlenen standartlar doğrultusunda analizden başarılı geçmeli. Başarılı geçmesi durumunda 3. adıma geçilmeli. Eğer standartları karşılamıyor ise CI hattının çalıştırılması durdurulmalıdır. (Build Breaker) . Gerekli düzenlemeler yapıldıktan sonra tekrar işlemler tekrar etmeli.
- Deployment işlemleri (CD) için uygulama artifactleri çıkartılmalı ve CD hattı tetiklenmelidir.
Unit Test
Unit Test, uygulama kodlarında bulunan en küçük birimlerin test edilmesidir. Birim (Unit) kelimesini ise yazılımlarda test edilebilecek en küçük yapı olarak tanımlayabiliriz.
Unit test geliştirmenin temel faydası hataları bulmaktan değil, yazılan kodun daha kaliteli yazılmasını sağlamasıdır. Test-Driven Development yazılım geliştirme tekniğini benimsenmiş bir geliştirmede yazılımda önce Unit testler geliştirilmektedir. Doğru bir şekilde geliştirilen unit testler ile birlikte yazılımın bileşenleri arasındaki karmaşıklığın önüne geçilerek henüz geliştirme aşamasında daha kaliteli bir yazılım ortaya koymaya yardımcı olacaktır.
Kullanılacak araç, uygulama geliştirirken kullandığınız programlama dili ve teknolojilere göre seçilmelidir. Bazı Unit Test Araçları : XUnit, JUnit, Emma, TestNG, …
Nerede Kullanmalıyım?
CI hattında uygulama build edildikten sonra, uygulama artifactleri çıkmadan önce çalıştırılmalıdır.
- Uygulama başarılı bir şekilde build olmalı.
- Build sonrası uygulama yazılmış unit testler çalıştırılmalıdır. Eğer tüm unit testler başarılı bir şekilde çalışıyor ise aşağıdaki adıma geçilir.
- Deployment işlemleri (CD) için uygulama artifactleri çıkartılmalı ve CD hattı tetiklenmelidir.
Azure Pipeline’da kurgulanmış örnek bir CI pipeline görüntüsü:
Unit testlerimizi başarılı bir şekilde çalıştırdık, kodlarımızı static kod analizinden geçirdik ve pipeline sonucunda uygulamaya ait artifactleri başarılı bir şekilde çıkarttık. Sırada yeni geliştirilmiş bir uygulamanın deploy edildikten sonra temel özelliklerinin çalışıp çalışmadığını test etmemiz gerekiyor.
API/Performance Testing
API testi, uygulama programlama arayüzlerini doğrudan ve işlevsellik, güvenilirlik, performans ve güvenlik beklentilerini karşılayıp karşılamadıklarını belirlemek için entegrasyon testinin bir parçası olarak test etmeyi içeren bir tür yazılım testidir.
Performans testi genel olarak bir sistemin belirli bir iş yükü altında yanıt verme ve kararlılık açısından nasıl performans gösterdiğini belirlemek için gerçekleştirilen bir test uygulamasıdır.
Eğer tüm deployment süreçleriniz otomatik bir şekilde pipeline aracılığı ile gerçekleşiyor ise uygulamaya ait servislerin yeni geliştirilen bir özellik sonrası servislerin başarılı bir şekilde çalışıp çalışmadığını ya da belli bir yük altında nasıl tepki verdiğini production deployment öncesinde test etmemiz gerekmektedir.
Bazı API Test Araçları : Karate DSL, Postman, Rest Assured, SoapUI, JMeter, …
Bazı Performance Test Araçları : Gatling, JMeter, WebLOAD, LoadNinja, …
Nerede Kullanmalıyım?
CD hattında uygulama test ortamına deploy edildikten sonra, test ortamında çalıştırılmalıdır.
- Uygulama test ortamına deploy edilir.
- Test ortamında api/perfomance testleri çalıştırılır. Var ise bu aşamadan sonra fonksiyonel testlerde çalıştırılmalıdır.
- Testlerden başarılı bir şekilde geçildiği taktirde production deployment işlemi gerçekleştirilir.
Azure Pipeline’da kurgulanmış örnek bir CD pipeline görüntüsü:
Sürekli olarak test otomasyonundan bahsederken aslında şu gerçeği unutmamak lazım; Test otomasyonunu yapmak için yapmaktansa bize fayda sağlayacağını düşüğümüz zamanlarda manuel testlerin yanına konumlandırdığımızda daha kaliteli çıktılar elde ediyor olacağız. Test vizyonunu oluşturmadan, manuel test süreçlerini oturtmadan, test senaryosu tasarımını öğrenmeden ve bunları uçtan uca işletmeden otomasyonda başarılı olmak çok da mümkün değil.
Umarım faydalı biz yazı olmuştur. Bir sonraki yazımda görüşmek dileğiyle. Sağlıkla kalın :)
