Farklı test türlerini projenize uygun, makul bir stratejide nasıl birleştireceğinizi öğrenin.
Tekrar hoş geldiniz! Son makalede, farklı test türlerine nasıl yaklaşılacağı ve neleri içerdikleriyle ilgili birçok temel bilgi verilmiş ve test türü tanımları netleştirilmişti. Bu küçük meme resmini hatırlıyor musunuz? Öğrendiğiniz tüm bu test türlerinin birlikte nasıl çalışabileceğini merak etmiş olabilirsiniz.
Şimdi tam olarak bunu öğreneceksiniz. Bu makalede, bu test türlerini makul stratejilerde nasıl birleştireceğiniz ve projenize uygun bir stratejiyi nasıl seçeceğiniz açıklanmaktadır.
Stratejileri daha iyi anlamak için çeşitli şekillerle karşılaştırabilirsiniz. Aşağıda, ilgili boyutları ve geliştirme kapsamları ile birlikte stratejilerin bir listesi verilmiştir.
Stratejileri daha yakından inceleyelim ve adlarının anlamını öğrenelim.
Test hedeflerini belirleyin: Bu testlerle ne elde etmek istiyorsunuz?
İyi bir strateji oluşturmaya başlamadan önce test hedefinizi belirleyin. Uygulamanızın yeterince test edildiğini ne zaman düşünürsünüz?
Yüksek test kapsamına ulaşmak, geliştiriciler için test konusunda genellikle nihai hedef olarak görülür. Ancak bu her zaman en iyi yaklaşım mıdır? Test stratejisine karar verirken göz önünde bulundurmanız gereken başka bir kritik faktör daha olabilir: Kullanıcılarınızın ihtiyaçlarını karşılamak.
Geliştirici olarak başka birçok uygulama ve cihaz da kullanırsınız. Bu açıdan, tüm bu sistemlerin "çalışması" için onlara güvenen bir kullanıcısınız. Uygulamalarını ve cihazlarını çalıştırmak için ellerinden geleni yapan sayısız geliştiriciye de güveniyorsunuz. Bu güveni boşa çıkarmamak için geliştirici olarak siz de elinizden geleni yapıyorsunuz. Bu nedenle, ilk hedefiniz her zaman çalışan bir yazılım sunmak ve kullanıcılarınıza hizmet vermek olmalıdır. Bu durum, uygulama kalitesini sağlamak için yazdığınız testler için de geçerlidir. Kent C. Dodds, Static vs Unit vs Integration vs E2E Testing for Frontend Apps (Ön Uç Uygulamaları için Statik, Birim, Entegrasyon ve E2E Testleri) başlıklı yayınında bu konuyu çok iyi özetliyor:
Testleriniz yazılımınızın kullanım şekline ne kadar benzerse size o kadar fazla güven verebilir.
Yazan: Kent C. Dodds
Kent bunu testlere güven kazanmak olarak tanımlıyor. Uygun bir test türü seçerek kullanıcılara ne kadar yaklaşırsanız testlerinizin geçerli sonuçlar vereceğine o kadar güvenebilirsiniz. Başka bir deyişle, piramitte ne kadar yukarı çıkarsanız o kadar çok güven kazanırsınız. Peki, piramit nedir?
Test stratejilerini belirleme: Test stratejisi nasıl seçilir?
İlk adım olarak, gereksinimlerin hangi kısımlarının karşılandığından emin olmak için kontrol etmeniz gerektiğini belirleyin. Hangi test türlerini kullanacağınızı ve verimli bir maliyet yapısını korurken en yüksek güveni hangi ayrıntı düzeyinde elde edebileceğinizi öğrenin. Birçok geliştirici bu konuyu benzetmeler kullanarak ele alır. En yaygın olanları, iyi bilinen klasik yöntemle başlayarak aşağıda bulabilirsiniz.
Klasik: Test piramidi
Test stratejilerini araştırmaya başladığınızda, muhtemelen ilk analoji olarak test otomasyonu piramidiyle karşılaşırsınız. Mike Cohn bu kavramı "Succeeding with Agile" adlı kitabında tanıtmıştır. Daha sonra Martin Fowler, Pratik Test Piramidi makalesinde bu kavramı daha da genişletti. Piramidi görsel olarak şu şekilde temsil edebilirsiniz:
Bu çizimde gösterildiği gibi test piramidi üç katmandan oluşur:
Birim. Bu testler, hızlı bir şekilde yürütüldükleri ve bakımları kolay olduğu için piramidin taban katmanında yer alır. İzole edilmişlerdir ve en küçük test birimlerini hedeflerler. Örneğin, çok küçük bir ürün için tipik bir birim testini inceleyin.
Entegrasyon. Bu testler, kabul edilebilir bir yürütme hızına sahip oldukları ancak sizi kullanıcıya birim testlerinden daha fazla yaklaştırdıkları için piramidin ortasında yer alır. Entegrasyon testine örnek olarak API testi verilebilir. Bileşen testlerini de bu türde sınıflandırabilirsiniz.
Uçtan uca testler (Kullanıcı arayüzü testleri olarak da bilinir). Bu testler, gerçek bir kullanıcıyı ve etkileşimini simüle eder. Bu tür testlerin yürütülmesi daha fazla zaman alır ve bu nedenle daha pahalıdır. Piramidin en üstünde yer alırlar.
Güven ve kaynaklar
Daha önce kısaca değindiğimiz gibi, katmanların sırası tesadüf değildir. Öncelikleri ve bunlara karşılık gelen maliyetleri gösterirler. Bu sayede her katman için kaç test yazmanız gerektiği konusunda net bir fikir edinebilirsiniz. Bunu test türlerinin tanımında görmüştünüz.
Uçtan uca testler kullanıcılarınıza en yakın testler olduğundan, uygulamanızın amaçlandığı gibi çalıştığına dair en yüksek güveni sağlar. Ancak eksiksiz bir uygulama yığını ve simüle edilmiş bir kullanıcı gerektirdiklerinden potansiyel olarak en pahalı testlerdir. Bu nedenle güven, testleri yürütmek için ihtiyaç duyduğunuz kaynaklarla doğrudan rekabet halindedir.
Piramit, birim testlerine daha fazla odaklanmanızı ve uçtan uca testlerin kapsadığı senaryolara kesin olarak öncelik vermenizi sağlayarak bu sorunu çözmeye çalışır. Örneğin, en önemli kullanıcı yolculuklarınız veya kusurlara en açık olan yerler. Martin Fowler'ın da vurguladığı gibi, Cohn'un piramidindeki en önemli iki nokta şunlardır:
- Farklı ayrıntı düzeylerinde testler yazın.
- Seviyeniz yükseldikçe test sayınız azalmalıdır.
Piramit evrim geçirdi. Test piramitlerinin uyarlamaları
Birkaç yıldır tartışmalar piramit etrafında dönüyor. Piramit, test stratejilerini aşırı basitleştiriyor, birçok test türünü dışarıda bırakıyor ve artık gerçek dünyadaki tüm projelere uymuyor. Bu nedenle yanıltıcı olabilir. Piramidin şekli bozulmuş mu? Guillermo Rauch'un bu konuda bir fikri var:
Testler yazın. Çok fazla değil. Çoğunlukla entegrasyon.
Guillermo Rauch tarafından
Bu konuyla ilgili en sık alıntılanan sözlerden biri olan bu ifadeyi inceleyelim:
- "Test yaz". Bunun nedeni yalnızca güven oluşturması değil, aynı zamanda bakımda zaman kazandırmasıdır.
- "Çok fazla değil". %100 kapsam her zaman iyi değildir çünkü bu durumda testleriniz önceliklendirilmez ve çok fazla bakım yapılması gerekir.
- "Çoğunlukla entegrasyon". Burada da entegrasyon testleri vurgulanır: Makul bir yürütme süresiyle günlük olarak yüksek bir güven düzeyi sağlayarak en fazla işletme değerini sunarlar.
Bu durum, test piramidi hakkında tekrar düşünmenize ve odağınızı entegrasyon testine kaydırmanıza neden olur. Son birkaç yılda birçok uyarlama önerildi. En yaygın olanlara göz atalım.
Test amaçlı elmas
İlk uyarlama, test piramidinde görüldüğü gibi birim testine yapılan aşırı vurguyu ortadan kaldırır. Birim testlerinde %100 kapsama ulaştığınızı varsayalım. Ancak bir sonraki yeniden düzenleme işleminizde bu birim testlerinin çoğunu güncellemeniz gerekir ve bunları atlamak isteyebilirsiniz. Bu nedenle aşınırlar.
Sonuç olarak ve entegrasyon testine daha fazla odaklanılmasıyla birlikte aşağıdaki şekil ortaya çıkabilir:
Piramit, elmasa dönüşür. Önceki üç katmanı farklı bir boyutta görebilirsiniz. Birim katmanı kesilmiştir:
- Birim. Birim testlerini daha önce tanımladığınız şekilde yazın. Ancak bu testler zamanla geçerliliğini yitirebileceğinden önceliklendirme yapın ve yalnızca en kritik senaryoları ele alın.
- Entegrasyon. Bildiğiniz entegrasyon testleri, tek birimlerin kombinasyonunu test eder.
- E2E. Bu katman, test piramidine benzer şekilde kullanıcı arayüzü testlerini işler. Yalnızca en kritik test durumları için uçtan uca testler yazmaya dikkat edin.
Petek test ediliyor
Spotify tarafından sunulan, test elmasına benzeyen ancak mikro hizmet tabanlı yazılım sistemleri için daha da özelleştirilmiş başka bir uyarlama daha vardır. Test peteği, mikro hizmet tabanlı bir yazılım sistemi için yazılacak testlerin ayrıntı düzeyi, kapsamı ve sayısıyla ilgili başka bir görsel analojidir. Mikro hizmetler küçük boyutlu olduğundan en büyük karmaşıklık hizmetin kendisinde değil, diğer hizmetlerle etkileşiminde ortaya çıkar. Bu nedenle, mikro hizmetler için test stratejisi öncelikle entegrasyon testlerine odaklanmalıdır.
Bu şekil bize bal peteğini hatırlatır, bu nedenle adı da petektir. Aşağıdaki katmanlara sahiptir:
- Entegre testler. Spotify'ın makalesinde J. B. Rainsberger'ın tanımını kullanabiliriz: "Başka bir sistemin doğruluğuna göre başarılı veya başarısız olacak bir test." Bu tür testlerde dikkate almanız gereken harici bağımlılıklar vardır. Diğer yandan, sisteminiz diğer sistemleri bozan bir bağımlılık olabilir. Diğer benzetmelerdeki uçtan uca testlere benzer şekilde, bu testleri dikkatli bir şekilde ve yalnızca en önemli durumlarda kullanın.
- Entegrasyon testleri. Diğer uyarlamalarda olduğu gibi bu katmana odaklanmanız gerekir. Bu testler, hizmetinizin doğruluğunu daha izole bir şekilde ancak diğer hizmetlerle birlikte doğrular. Bu, testlerin başka sistemleri de içereceği ve örneğin API testleri aracılığıyla etkileşim noktalarına odaklanacağı anlamına gelir.
- Uygulama ayrıntılarıyla ilgili testler. Bu testler, birim testlerine benzer. Birim testleri, kodun doğal olarak izole edilmiş ve bu nedenle kendi iç karmaşıklığına sahip olan bölümlerine odaklanan testlerdir.
Bu test stratejisi hakkında daha fazla bilgi edinmek istiyorsanız Martin Fowler'ın test piramidini petekle karşılaştıran yayınını ve Spotify'ın orijinal makalesini inceleyin.
Test kupası
Entegrasyon testlerine tekrar tekrar odaklanıldığını görebilirsiniz. Ancak önceki makalede karşılaştığınız başka bir tür, teoride test değildir ancak yine de bir test stratejisinde dikkate almanız gereken önemli bir unsurdur. Statik analiz, test piramidinde ve şimdiye kadar gördüğünüz uyarlamaların çoğunda yer almaz. Entegrasyon testlerine odaklanmaya devam ederken statik analizi de hesaba katan test kupası uyarlaması vardır. Test kupası, Guillermo Rauch'un daha önceki bir alıntısından esinlenerek Kent C. tarafından geliştirilmiştir. Dodds:
Test kupası, testlerin ayrıntı düzeyini biraz farklı bir şekilde gösteren bir analojidir. Dört katmanı vardır:
- Statik analiz. Bu benzetmede hayati bir rol oynar ve yalnızca daha önce açıklanan hata ayıklama adımlarını çalıştırarak yazım hatalarını, stil hatalarını ve diğer hataları yakalamanıza olanak tanır.
- Birim testleri. En küçük biriminizin uygun şekilde test edilmesini sağlarlar ancak test kupası, test piramidi kadar bunlara vurgu yapmaz.
- Entegrasyon. Diğer uyarlamalarda olduğu gibi, maliyeti ve daha yüksek güveni en iyi şekilde dengelediği için ana odak noktası budur.
- Kullanıcı arayüzü testleri. Uçtan uca ve görsel testler de dahil olmak üzere, test piramidindeki rollerine benzer şekilde test kupasının en üstünde yer alırlar.
Test kupası hakkında daha fazla bilgi edinmek için Kent C. Dodds'un blog yayınını inceleyin. Dodds'un makalesini okuyun.
Kullanıcı arayüzü odaklı diğer yaklaşımlar
Bunlar iyi hoş ama stratejinize ister "piramit", ister "petek", ister "elmas" deyin, yine de bir şeyler eksik kalıyor. Test otomasyonu değerli olsa da manuel testin hâlâ gerekli olduğunu unutmamak önemlidir. Otomatik testler, rutin görevleri azaltmalı ve kalite kontrol mühendislerinin önemli alanlara odaklanmasını sağlamalıdır. Otomasyon, manuel testin yerini almak yerine onu tamamlamalıdır. En iyi sonuçları elde etmek için manuel testleri otomasyonla entegre etmenin bir yolu var mı?
Test dondurma külahı ve test yengeç
Test piramidinin, kullanıcı arayüzü odaklı test yöntemlerine daha fazla odaklanan iki uyarlaması vardır. Her ikisi de yüksek güven avantajına sahiptir ancak test işlemi hızı daha yavaş olduğu için doğal olarak daha maliyetlidir.
İlk dondurma külahı, ters çevrilmiş bir piramit gibi görünüyor. Manuel test adımı olmadan, test pizzası olarak da bilinir.
Dondurma külahı, manuel veya kullanıcı arayüzü testine daha fazla, birim testine ise en az odaklanır. Genellikle geliştiricilerin test stratejisi hakkında yalnızca birkaç fikirle çalışmaya başladığı projelerde ortaya çıkar. Buz kodu, haklı olarak bir anti-pattern olarak kabul edilir. Kaynaklar ve manuel çalışma açısından maliyetlidir.
Test yengeci, test dondurma külahına benzer ancak uçtan uca ve görsel testlere daha fazla önem verir:
Bu test stratejisi bir yönü daha içerir: Uygulamanızın çalıştığını ve iyi göründüğünü doğrular. Test yengeci, önceki makalede tanımlanan görsel testin önemini vurgular. Bileşen ve API testi olarak ikiye ayrılan entegrasyon testi daha da arka plana geçer ve birim testi burada daha da ikincil bir rol oynar. Bu test stratejisiyle ilgili daha fazla bilgiyi test yengeci hakkındaki bu makalede bulabilirsiniz.
Daha maliyetli olmalarına rağmen bu iki test stratejisinin de kullanım alanları vardır. Örneğin, daha az testin gerektiği veya daha az karmaşıklığın ele alınması gereken daha küçük projelerde kullanılabilirler. Bu durumda, entegrasyon testine odaklanan kapsamlı bir test stratejisi gereğinden fazla karmaşık olabilir.
Bu iki test stratejisi daha maliyetli olsa da daha az test gerektiren ve çok fazla karmaşıklık içermeyen küçük projelerde kullanılabilir. Bu durumda, entegrasyon testine odaklanan tam ölçekli bir test stratejisi gereksiz yere karmaşık olabilir.
Pratik öneriler: Strateji oluşturalım.
En yaygın test stratejilerini öğrendiniz. Klasik test piramidiyle başladınız ve birçok uyarlamasını öğrendiniz. Şimdi bunları ürününüz için değerlendirmeniz ve projeniz için en uygun olanına karar vermeniz gerekiyor. Bu sorunun yanıtı, herkesin sevdiği "Duruma göre değişir" ifadesiyle başlamalıdır. Ancak bu durum, verilerin doğruluğunu etkilemez.
Açıklananlar ve hatta açıklanmayanlar arasından en uygun test stratejisinin seçimi uygulamanıza bağlıdır. Mimarisine, gereksinimlerinize ve en önemlisi kullanıcılarınıza ve onların gereksinimlerine uygun olmalıdır. Tüm bunlar uygulamadan uygulamaya farklılık gösterebilir. Bu tamamen normaldir. En önemli hedefinizin, ders kitabı tanımına uymak değil, kullanıcılarınıza hizmet etmek olduğunu unutmayın.
Gerçek dünyadaki testleri birbirinden ayırmak ve ayrı ayrı tanımlamak genellikle zordur. Martin Fowler bile birim testleri örneğinde olduğu gibi farklı tanımların olumlu yönünü vurgular. Justin Searls'ün tweet'inde doğru bir şekilde belirttiği gibi:
[…] net sınırlar belirleyen, hızlı ve güvenilir bir şekilde çalışan ve yalnızca yararlı nedenlerle başarısız olan anlamlı testler yazın.
Justin Searls
Kullanıcıların karşılaşabileceği gerçek hataları bildiren testlere odaklanın ve hedefinizden sapmayın. Testler, yalnızca %100 kapsam sağlamak veya hangi test türünün hangi yüzdesinin yazılacağını tartışmak için değil, kullanıcıya fayda sağlayacak şekilde tasarlanmalıdır.
Kullanıcılarınızın karşılaşabileceği gerçek hayattaki hataları bildiren testlere odaklanın ve hedefinizden sapmayın. Testler, yalnızca %100 kapsam sağlamak veya belirli bir test türünün yüzde kaçını yazmanız gerektiği konusunda tartışmalara yol açmak için değil, kullanıcıya fayda sağlayacak şekilde tasarlanmalıdır.