Farklı test türlerini projenizle eşleşen makul bir stratejide nasıl birleştireceğinizi keşfedin.
Tekrar hoş geldiniz! Son makalede, farklı test türlerine ve bunların içeriğine nasıl yaklaşılması gerektiğine dair birçok temel fikir sunulmuş ve test türü tanımları netleştirilmiştir. 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.
Sonra tam olarak bunu öğreneceksiniz. Bu makalede, bu test türlerini makul stratejilerle nasıl birleştireceğiniz ve projenize uygun stratejiyi nasıl seçeceğiniz açıklanmaktadır.
Anlamlarını daha iyi kavrayabilmek için stratejileri bir dizi şekille karşılaştırabilirsiniz. Aşağıda, ilgili boyutlar ve geliştirme kapsamlarına sahip stratejilerin bir listesi verilmiştir.
Stratejilere daha yakından bakalım ve isimlerinin ne anlama geldiğini öğrenelim.
Test hedeflerini belirleyin: Bu testlerle neyi başarmak istiyorsunuz?
İyi bir strateji oluşturmaya başlamadan önce test hedefinizi belirleyin. Uygulamanızın ne zaman yeterli test edildiğini düşünüyorsunuz?
Test söz konusu olduğunda, geliştiricilerin nihai hedefi genellikle yüksek test kapsamına ulaşmak olarak görülür. Peki bu her zaman en iyi yaklaşım mıdır? Test stratejisine karar verirken kullanıcılarınızın ihtiyaçlarına cevap veren bir diğer önemli faktör daha olabilir.
Bir geliştirici olarak, başka birçok uygulama ve cihaz da kullanıyorsunuz. Bu açıdan, tüm bu sistemlerin "sorunsuz şekilde çalışması" için size güvenen kullanıcı sizsiniz. Bunun sonucunda, uygulama ve cihazlarının çalışmasını sağlamak için ellerinden geleni yapacakları konusunda sayısız geliştiriciye güveniyorsunuz. Bu durumu tersine çevirmek için, bir geliştirici olarak siz de bu güveni korumak için çabalarsınız. Dolayısıyla ilk hedefiniz her zaman çalışan bir yazılım göndermek ve kullanıcılarınıza hizmet etmek olmalıdır. Bu politika, uygulama kalitesinden emin olmak için yazdığınız testleri de kapsar. Kent C. Dodds, Static vs Unit vs Integration vs. for Frontend Apps yayınında (Static vs Unit vs Integration vs.) bu durumu çok iyi özetliyor:
Testleriniz yazılımınızın kullanım şekline ne kadar çok benzerse size o kadar güven verebilirler.
Hazırlayan: Kent C. Dodds
Kent, bunu testlerde güven kazanma olarak tanımlar. Uygun bir test türü seçerek kullanıcılara ne kadar yaklaşırsanız, testlerinizin geçerli sonuçlar vereceğine o kadar fazla güvenebilirsiniz. Diğer bir deyişle, piramide ne kadar yukarı tırmanırsanız o kadar öz güveniniz olur. Peki, piramit nedir?
Test stratejilerini belirleme: Test stratejisi nasıl seçilir?
İlk adım olarak, şartların 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 hangi ayrıntı düzeyinde, verimli bir maliyet yapısını korurken en yüksek güveni elde edebileceğinizi öğrenin. Birçok geliştirici bu konuya benzetmeler kullanarak yaklaşır. En yaygın olanları, bilinen klasiklerden başlayarak burada bulabilirsiniz.
Klasik: Test piramidi
Test stratejileri aramaya başlar başlamaz, muhtemelen ilk benzetmenin yapıldığı test otomasyon piramidi ile karşılaşırsınız. Mike Cohn bu kavramı "Çevik ile Başarıya Ulaşma" adlı kitabında açıklamıştır. Daha sonra Martin Fowler, Uygulamalı Test Piramidi makalesinde bu kavramın kapsamını genişletmiştir. Piramidi görsel olarak aşağıdaki şekilde temsil edebilirsiniz:
Bu çizimde gösterildiği gibi, test piramidi üç katmandan oluşur:
Birim. Bu testleri piramidin temel katmanında bulabilirsiniz, çünkü hızlı yürütülür ve bakımları kolay olur. Bunlar izoledir ve en küçük test birimlerini hedefler. Örneğin, çok küçük bir ürün için tipik bir birim testine bakın.
Entegrasyon. Bu testler piramidin ortasındadır, çünkü kabul edilebilir bir yürütme hızına sahiptirler, ancak sizi, birim testlerine kıyasla kullanıcıya daha da yakınlaştırır. Entegrasyon testlerine örnek olarak API testi verilebilir. Bileşen testlerini de bu tür olarak sınıflandırabilirsiniz.
E2E testleri (kullanıcı arayüzü testleri olarak da adlandırılır). Bu testler gerçek bir kullanıcıyı ve onun etkileşimini simüle eder. Bu tür testlerin yürütülmesi daha fazla zaman gerektirdiği için daha pahalıdır. Piramidin üst kısmındadırlar.
Güven ve kaynaklar
Daha önce kısaca değindiğimiz gibi, katmanların sırası birbiriyle tesadüf değildir. Bunlar, öncelikleri ve ilgili maliyetleri gösterir. Bu, her bir katman için kaç test yazmanız gerektiği konusunda net bir resim sağlar. Bunu, test türlerinin tanımında zaten görmüştünüz.
E2E testleri kullanıcılarınıza en yakın testler olduğundan uygulamanızın beklendiği gibi çalıştığı konusunda size en yüksek güveni sağlar. Ancak bu uygulamalar, eksiksiz bir uygulama yığını ve bir simüle edilmiş kullanıcı gerektirdiğinden aynı zamanda potansiyel olarak en pahalı seçenektir. Dolayısıyla güven, testleri yürütmek için ihtiyaç duyduğunuz kaynaklarla doğrudan rekabet halindedir.
Piramit, birim testlerine daha fazla odaklanmanızı ve E2E testlerinde yer alan vakalara sıkı bir öncelik vermenizi sağlayarak bu sorunu çözmeye çalışır. Örneğin, en önemli kullanıcı yolculuklarınız veya kusurlara en açık yerler. Martin Fowler'ın vurguladığı gibi, Cohn piramidindeki en önemli iki nokta şu şekildedir:
- Testleri farklı ayrıntı düzeylerinde yazın.
- Seviyeniz yükseldikçe daha az test yapmanız gerekir.
Piramit gelişti! Test piramitlerinin uyarlamaları
Bu piramidin konusu yıllardır tartışılıyor. Piramit, test stratejilerini fazla basitleştirmiş gibi görünüyor, birçok test türünü dışarıda bırakıyor ve artık tüm gerçek projelere uygun değil. Bu nedenle, yanıltıcı olabilir. Piramidin şekli mi bozulmuş? Guillermo Rauch'un bu konuda bir fikri var:
Testleri yazın. Çok fazla değil. Çoğunlukla entegrasyon.
Oluşturan: Guillermo Rauch
Bu ay, bu konuda en sık alıntılanan alıntılardan biridir. Şimdi bu alıntıyı ayrıntılı olarak inceleyelim:
- "Test yazın". Güven kazandırdığı için aynı zamanda bakımda zaman kazandırdığı için de.
- "Çok fazla değil". 0 kapsam her zaman iyi değildir çünkü bu durumda testinize öncelik verilmemiştir ve çok fazla bakım yapılacaktır.
- "Büyük ölçüde entegrasyon". Burada da yine entegrasyon testlerine odaklanılır. Bu testler, makul bir yürütme süresini korurken size günlük yüksek güven düzeyi sağlayarak iş açısından en değerli değere sahiptir.
Böylece tekrar test piramidi üzerine düşünüp odağınızı entegrasyon testine kaydırırsınız. Son birkaç yıldır çok sayıda uyarlama önerilmiştir. Şimdi en yaygın olanlara bakalım.
Test elması
İlk uyarlama, test piramidinde görüldüğü gibi birim testi üzerindeki aşırı vurguyu ortadan kaldırır. Birim testlerinde% 100 kapsama ulaştığınızı düşünün. Ancak, bir sonraki düzenlemenizde, bu birim testlerinin birçoğunu güncellemeniz gerekecek ve bunları atlamak isteyebilirsiniz. Bu yüzden aşındırırlar.
Bunun sonucunda, entegrasyon testine daha yoğun odaklanıldığında aşağıdaki şekil ortaya çıkabilir:
Piramit bir elmasa dönüşür. Önceki üç katmanı farklı boyutta görebilirsiniz. Birim katmanı kesilmiştir:
- Birim. Birim testlerini daha önce tanımladığınız şekilde yazın. Bununla birlikte, bu araçlar aşınma eğiliminde olduğundan, önceliklendirerek ve yalnızca en kritik durumları kapsamaktadır.
- Entegrasyon. Entegrasyon, bildiğiniz gibi tek birimlerin kombinasyonunu test eder.
- E2E'ye dokunun. Bu katman, test piramidine benzer şekilde kullanıcı arayüzü testlerini işler. E2E testlerini yalnızca en kritik test durumları için yazmaya dikkat edin.
Petek testi
Spotify tarafından kullanıma sunulan, test elmasına benzeyen ancak mikro hizmet tabanlı yazılım sistemleri için daha da uzmanlaşmış başka bir uyarlama vardır. Petek testi, mikro hizmet tabanlı bir yazılım sistemi için yazılacak testlerin ayrıntı düzeyi, kapsam ve sayısı açısından başka bir görsel benzerliktir. Küçük boyutları nedeniyle bir mikro hizmetteki en önemli karmaşıklık, hizmetin kendisi içinde değil, diğer hizmetlerle etkileşim biçimindedir. Bu nedenle, bir mikro hizmet için test stratejisi öncelikle entegrasyon testlerine odaklanmalıdır.
Bu şekil bize peteği hatırlatır, dolayısıyla adını da hatırlatır. Aşağıdaki katmanlara sahiptir:
- Entegre testler. Spotify'ın bu makalesinde J. B. Rainsberger'in bu katmanı tanımlaması gerekir: "Başka bir sistemin doğruluğuna göre başarılı veya başarısız olacak bir test." Bu tür testler, göz önünde bulundurmanız gereken dış bağımlılıklar içerir. Tersine, sisteminiz diğer sistemleri bozan bir bağımlılık olabilir. Diğer benzetimlerdeki E2E testlerine benzer şekilde, bu testleri yalnızca en önemli durumlar için dikkatli bir şekilde kullanın.
- Entegrasyon testleri. Diğer uyarlamalarda olduğu gibi, bu katmana odaklanmalısınız. Hizmetinizin doğruluğunu daha izole bir şekilde ancak yine de diğer hizmetlerle birlikte doğrulayan testleri içerir. Bu durum, testlerin diğer 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. Bunlar, kodun doğal olarak izole edilmiş ve bu nedenle kendi iç karmaşıklıklarına sahip kısımlarına odaklanan testlerdir.
Bu test stratejisi hakkında daha fazla bilgi edinmek isterseniz Martin Fowler'ın test piramidini bal peteğiyle karşılaştırdığı gönderiyi ve Spotify'ın orijinal makalesini inceleyin.
Test kupası
Entegrasyon testlerinde tekrarlanan bir odak görebilirsiniz. Ancak, önceki makalede karşılaştığınız bir diğer tür, teoride test yapmak değildir, ancak yine de bir test stratejisinde göz önünde bulundurmanız gereken önemli bir unsurdur. Test piramidinde ve şimdiye kadar gördüğünüz uyarlamaların çoğunda statik analiz eksiktir. Burada, entegrasyon testlerine odaklanmayı sürdürürken statik analizi dikkate alan test kupası uyarlaması var. Test kupası, Guillermo Rauch'un önceki sözlerinden yola çıkarak Kent C tarafından geliştirildi. Makaleler:
Test kupası, testlerin ayrıntı düzeyini biraz daha farklı bir şekilde betimleyen bir benzerliktir. Dört katmanı vardır:
- Statik analiz. Bu benzetmede çok önemli bir rol oynar ve yalnızca, daha önce ana hatlarıyla belirtilen hata ayıklama adımlarını uygulayarak yazım hatalarını, stil hatalarını ve diğer hataları yakalayabilmenizi sağlar.
- Birim testleri. Bunlar, en küçük biriminizin uygun bir şekilde test edilmesini sağlar, ancak test kupası bunları test piramidiyle aynı ölçüde vurgulamaz.
- Entegrasyon. Bu yöntem, diğer uyarlamalarda olduğu gibi maliyeti ve güven düzeyini en iyi şekilde dengelediğinden ana odak noktasıdır.
- Kullanıcı arayüzü testleri. E2E testleri ve görsel testler gibi bu testler, test piramidindeki rollerine benzer şekilde test kupasının en üstünde yer alıyor.
Test kupası hakkında daha fazla bilgi edinmek için Kent C. daha fazla bilgi edinin.
Kullanıcı arayüzü odaklı bazı diğer yaklaşımlar
Tüm bunlar gayet güzel. Ancak stratejinize nasıl "piramit", "bal peteği" veya "elmas" dediğiniz ne olursa olsun hâlâ eksik bir şey var. Test otomasyonu değerli olsa da manuel test yapmanın önemini unutmamak gerekir. Otomatik test, rutin görevleri hafifletir ve kalite güvencesi mühendislerini önemli alanlara odaklanmaya teşvik eder. Manuel test yerine otomasyon, onu tamamlamalıdır. Optimum sonuçlar için manuel testi otomasyonla entegre etmenin bir yolu var mı?
Buz külahı ve yengeç testi
Test piramidinin, kullanıcı arayüzü odaklı bu test yöntemlerine daha fazla odaklanan iki farklı uyarlaması bulunmaktadır. Her ikisinin de yüksek güven avantajı avantajı vardır, ancak test yürütme yavaş olduğu için doğal olarak daha maliyetlidir.
İlki, test buz konisi, tersten piramit olarak görünür. Manuel test adımı olmadan, test pizzası olarak da bilinir.
Buz külahı daha çok manuel veya kullanıcı arayüzü testlerine, en az ise birim testlerine odaklanır. Bu süreç genellikle geliştiricilerin test stratejisi konusunda sadece birkaç fikirle çalışmaya başladıkları projelerde şekillenir. Buz kodu, bir anti kalıp olarak kabul edilir ve haklı olarak. Kaynaklar ve manuel iş açısından maliyeti yüksektir.
Test yengeci, test buz konisine benzer, ancak E2E'ye ve görsel teste daha fazla ağırlık verir:
Bu test stratejisinin bir yönü daha vardır: Uygulamanızın çalıştığını ve iyi göründüğünü doğrular. Test yengeci, bir önceki makalede tanımlanan görsel testin önemini vurgular. Bileşen ve API testine ayrılmış entegrasyon testi, arka planda ilerler ve birim testi burada daha da ikincil bir rol oynar. Bu test stratejisiyle ilgili daha fazla bilgiyi test yengeciyle ilgili bu makalede bulabilirsiniz.
Bu iki test stratejisi daha maliyetli olsa da bir yere sahiptir: Örneğin, daha az testin veya daha az karmaşıklığın ele alınması gereken daha küçük projelerde. Bu durumda, entegrasyon testine odaklanan tam teşekküllü bir test stratejisi, gereğinden fazla tasarlanabilir.
Bu iki test stratejisi daha maliyetli olsa da, örneğin daha az test gerektiren ve çok fazla karmaşıklığı kapsamayan daha küçük projelerde de geçerlidir. Bu durumda, entegrasyon testine odaklanan tam ölçekli bir test stratejisi gereksiz ölçüde karmaşık olabilir.
Pratik öneri: Strateji oluşturalım!
Artık en yaygın test stratejilerini öğrendiniz. Klasik piramidle (test piramidi) başladınız ve bu piramidin birçok uyarlamasını öğrendiniz. Şimdi bunları ürününüz için değerlendirmeniz ve projeniz için hangisinin en iyi olduğuna karar vermeniz gerekiyor. Bu sorunun yanıtı, herkesin en sevdiği "Duruma göre değişir" ifadesiyle başlamalıdır. Ancak bu, doğruluğunun azalmasına neden olmaz.
Açıklananlar arasından en uygun test stratejisinin seçimi (hatta dahil edilmeyenler) uygulamanıza bağlıdır. Bu proje mimarinizi, gereksinimlerinizi ve kullanıcılarınızla birlikte gereksinimlerini karşılamalı. Bu özellikler uygulamadan uygulamaya farklılık gösterebilir. Bu tamamen normal bir durumdur. En önemli hedefinizin ders kitabındaki bir tanımı değil, kullanıcılarınıza hizmet etmek olduğunu unutmayın.
Gerçek dünyayla ilgili testlerin birbirinden ayrılması ve tek tek tanımlanması genellikle zordur. Örneğin, birim testlerinde olduğu gibi Martin Fowler farklı tanımların olumlu yönünü vurgular. Justin Searls tweet'inde doğru şekilde söylüyor:
[...] Net sınırlar oluşturan, hızlı ve güvenilir şekilde çalışan ve yalnızca yararlı nedenlerle başarısız olan anlamlı testler yazın.
Hazırlayan: Justin Searls
Kullanıcıların karşılaşabileceği gerçek hataları bildiren ve dikkatinin dağılmamasını sağlayan testlere odaklanın. Testler sadece% 100 kapsam sağlamak veya hangi test türünün hangi yüzdesinin yazılacağını tartışmak yerine, kullanıcıya fayda sağlayacak şekilde tasarlanmalıdır.
Kullanıcılarınızın karşılaşabileceği ve dikkatinin dağılmaması için gerçek hayattaki hataları bildiren testlere odaklanın. Testler kullanıcıya fayda sağlayacak şekilde tasarlanmalı, yalnızca% 100 kapsam sağlamalı veya belirli bir test türünün yüzde kaçının yazılması gerektiği konusunda tartışmalar başlatmamalıdır.