QA’lere Düşen API Testleri Neler? API Testi Mantığı.
Merhaba,
API kısaltmasını sıkça duyuyoruz peki nedir bu API? Tamam testini yazacağız da önce neyin testini yazacağımızı bilirsek süreç çok daha sağlıklı ilerleyecektir. API yani “Application Programming Interface”; “Uygulama Programlama Arabirimi” dediğimiz şey, basitçe bir uygulamanın kendisi ile nasıl iletişim kurulacağını belirlediği yapı olarak tanımlanabilir. Detaylı bilgi için bu yazıya gidebilirsiniz, ama şu an bizim konumuz bu değil. :)
Daha önce API testi yazmamış QA’ler için bu kısım biraz havada kalan, net bilgiler edinilmemiş halde oluyor genelde. Bu yazıda en temel haliyle QA’e düşen API testlerini anlatmaya çalışacağım.
Bir QA tarafından Api testi, kodsal bir değişiklikte ortamın hala stabil olduğunu garanti etmek amacıyla yazılır ve en temel haliyle iki ana parçaya ayrılır:
1- Contract Test
2- Acceptance Test
Önce Contract test’ten bahsedelim; contract dediğimiz şey herhangi biriyle anlaşmak anlamına gelir. Contract test API-API arasına, API-Client arasına yazılabilir. İki taraf arasında “ben seni x,y,z istekleriyle çağıracağım sen de bana bunları dönecek misin” iletişiminde contract’lar belirlenir. Contract’ın bozulmadığını garanti etmek için ortada bir otorite olması gerekiyor. Burada otorite dediğimiz bizim yazdığımız test oluyor. API koddan herhangi bir değişiklik yaptığında, koddan bir şeyler sildiğinde, koda yeni alanlar eklediğinde bu testleri çalıştırırız ki yeni yapılan geliştirmelerle, diğer API’lar veya anlaştığı Client’lar ile arasında anlaştığı yapının bozulmamış olduğunu garanti edelim. Bu testler de tıpkı diğer tüm testlerde olduğu gibi sürekli güncellenmeli. Eğer bir API anlaştığı diğer API’lar veya Client’lar ile ortak karar vererek bir anlaşmayı değiştirirse contract testi bu bağlamda güncellenmeli.
Acceptance test’ten bahsetmek gerekirse; acceptance kabul anlamına gelir. Acceptance test bir API’daki tüm caselerin, API’ın döndüğü tüm json attributeların value’larının, servisin döndüğü HTTP requestlerinin kontrol edilmesi amacıyla yazılır. Acceptance test de tıpkı contract test gibi herhangi bir kod güncellemesinde var olan yapının bozulmamış olmasını garanti eder. Örneğin bir endpointten dönen response’ta address alanı string dönmeli ve kodda bu yanlışlıkla integer’a çevrildiyse test hata alacak ve production ortamına yanlış bir kod deploy edilmemiş olacak. Veya yine başka bir örnek vermek gerekirse requestte “null” gönderilen bir alanda HTTP 500 dönmeliyse, kodda herhangi bir değişiklikte bu case atlandıysa testimiz hata alacak.
Özetlemek gerekirse; API testini QA gözüyle 2 parça olarak düşünmeliyiz. İlk önce ilgili API’ın belirlenmiş contract’larının testini, daha sonra acceptance testini yazmalıyız. API ile ilgili yazılan testler ortak olarak kodda yapılan hatalı bir değişiklikte o kodun yanlış bir şekilde production’a çıkmasını engellemek, API’ın bağlı olduğu diğer API veya Clientlar’ın hata almamasını sağlamak amacıyla yazılır. Her iki test de kod değişikliklerinde çalıştırılmalı ve kod refactorlerine göre testler güncellenmeli.
Umarım hoşunuza giden bir yazı olmuştur. Yorumlarınızı bekliyorum. Bu arada yazıyı beğendiyseniz alkış ile beni haberdar edebilirsiniz.
