Farklı test türlerini projenizle eşleşen makul bir stratejide nasıl birleştireceğinizi öğrenin.
Tekrar hoş geldiniz! Son makalede, farklı test türlerine nasıl yaklaşılacağı ve bunların neleri içerdiği hakkında birçok temel bilgi verilmiş ve test türü tanımları açıklanmıştır. Bu meme resmini hatırlıyor musunuz? Öğrendiğiniz tüm bu test türlerinin birlikte nasıl çalışabileceğini merak etmiş olabilirsiniz.
Ardından tam olarak bunu öğreneceksiniz. Bu makalede, bu test türlerinin makul stratejilerde nasıl birleştirileceği ve projenizle eşleşen bir stratejinin nasıl seçileceği hakkında bir giriş sunulmaktadır.
Anlamlarını daha iyi anlamak için stratejileri çeşitli şekillerle karşılaştırabilirsiniz. Aşağıda, ilgili boyut ve geliştirme kapsamlarını içeren stratejilerin listesi verilmiştir.
Stratejilere daha yakından bakalım ve adlarının arkasındaki anlamı öğ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 yeterince test edildiğini düşünüyorsunuz?
Test kapsamını artırmak, geliştiriciler için test konusunda genellikle nihai hedef olarak kabul edilir. Ancak bu her zaman en iyi yaklaşım mıdır? Test stratejisine karar verirken göz önünde bulundurulması gereken başka bir kritik faktör de kullanıcılarınızın ihtiyaçlarını karşılamaktır.
Geliştirici olarak başka birçok uygulama ve cihaz da kullanırsınız. Bu açıdan, tüm bu sistemlerin "sadece çalışmasına" güvenen bir kullanıcısınız. Sırayla, sayısız geliştiricinin uygulamalarını ve cihazlarını çalıştırmak için ellerinden geleni yapmasını bekliyorsunuz. Geliştirici olarak bu güveni geri kazanmak için de elinizden geleni yapıyorsunuz. Bu nedenle, ilk hedefiniz her zaman çalışan bir yazılım yayınlamak ve kullanıcılarınıza hizmet vermektir. Bu, uygulama kalitesini sağlamak için yazdığınız testleri de kapsar. Kent C. Dodds, Ön Uç Uygulamalar İçin Statik, Birim, Entegrasyon ve E2E Testi başlıklı makalesinde bu konuyu çok iyi özetliyor:
Testleriniz yazılımınızın kullanım şekline ne kadar benzerse size o kadar güven verebilir.
by Kent C. Dodds
Kent, bunu testlere güven duyma olarak tanımlıyor. Uygun bir test türünü seçerek kullanıcılara ne kadar yakın olursanız testlerinizin geçerli sonuçlar vereceğine o kadar güvenebilirsiniz. Diğer bir deyişle, piramidin üst basamaklarına çıktıkça kendinize olan güveniniz artar. Peki, piramit nedir?
Test stratejilerini belirleme: Test stratejisi seçme
İlk adım olarak, karşılandığından emin olmak için şartların hangi bölümlerini kontrol etmeniz gerektiğini belirleyin. Hangi test türlerinin kullanılacağını ve verimli bir maliyet yapısı korurken en yüksek güveni hangi ayrıntı düzeyinde elde edebileceğinizi öğrenin. Birçok geliştirici bu konuya benzetmeler yaparak yaklaşır. En yaygın olanları, bilinen klasikten başlayarak aşağıda bulabilirsiniz.
Klasik: Test piramidi
Test stratejileri aramaya başladığınızda muhtemelen ilk benzetme olarak test otomasyonu piramidine rastlarsınız. Mike Cohn bu kavramı "Succeeding with Agile" (Agile ile Başarılı Olma) adlı kitabında tanıtmıştır. Daha sonra Martin Fowler, Pratik Test Piramidi makalesinde bu kavramı genişletti. Piramidi görsel olarak aşağıdaki gibi temsil edebilirsiniz:
Bu çizimde gösterildiği gibi test piramidi üç katmandan oluşur:
Birim. Hızlı bir şekilde uygulandıkları ve bakımı kolay oldukları için bu testleri piramidin taban katmanında bulabilirsiniz. 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, kabul edilebilir bir yürütme hızına sahip oldukları ancak birim testlerinden daha fazla kullanıcıya yaklaştırdıkları için piramidin ortasında yer alır. Entegrasyon testi örneği 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 bilinir). Bu testler, gerçek bir kullanıcıyı ve kullanıcının etkileşimini simüle eder. Bu tür testlerin yürütülmesi daha fazla zaman aldığından daha pahalıdır. Bunlar piramidin en üst kısmında yer alır.
Güven ve kaynaklar
Daha önce kısaca değinildiği gibi, katmanların sırası tesadüf değildir. Öncelikleri ve ilgili maliyetleri gösterir. Bu sayede her katman için kaç test yazmanız gerektiğine dair net bir fikir edinebilirsiniz. Bunu test türlerinin tanımında görmüştünüz.
Kullanıcılarınıza en yakın testler uçtan uca testler olduğundan, uygulamanızın istenen şekilde çalıştığından emin olmanızı sağlarlar. Ancak, eksiksiz bir uygulama yığını ve simüle edilmiş bir kullanıcı gerektirdiğinden, potansiyel olarak en pahalı yöntemlerdir. 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ığı durumlara kesinlikle ö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'un da vurguladığı gibi, Cohn'un piramidindeki en önemli iki nokta şunlardır:
- Farklı ayrıntı düzeylerine sahip testler yazın.
- Seviyeniz yükseldikçe daha az test yapmanız gerekir.
Piramit yenilendi. Test piramitlerinin uyarlamaları
Birkaç yıldır piramit hakkında tartışmalar yapılıyor. Piramit, test stratejilerini 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. Piramit şeklini kaybetti mi? Guillermo Rauch bu konudaki görüşlerini şöyle açıklıyor:
Testler yazın. Çok fazla değil. Çoğunlukla entegrasyon.
Guillermo Rauch tarafından
Bu konuda en çok alıntı yapılan sözlerden biri olan bu ifadeyi inceleyelim:
- "Test yazma". Bunun nedeni yalnızca güven kazanmak değil, aynı zamanda bakım konusunda zaman kazanmaktır.
- "Çok fazla değil". %100 kapsama her zaman iyi değildir. Çünkü testlerinize öncelik verilmez ve çok fazla bakım yapılması gerekir.
- "Çoğunlukla entegrasyon". Burada da vurgu, entegrasyon testlerine verilir: Makul bir yürütme süresi sağlarken günlük olarak yüksek güven düzeyi sunarak en fazla işletme değerine sahiptirler.
Bu durum, test piramidini tekrar düşünmenize ve odak noktanızı entegrasyon testine kaydırmanıza neden olur. Son birkaç yılda birçok uyarlama önerildi. En yaygın olanları inceleyelim.
Test elması
İlk uyarlamada, test piramidinde görüldüğü gibi birim testine aşırı vurgu yapılması kaldırılmıştır. Birim testlerinde% 100 kapsama oranına ulaştığınızı varsayalım. Ancak bir sonraki yeniden yapılandırmanızda bu birim testlerinin çoğunu güncellemeniz gerekir ve bunları atlamak isteyebilirsiniz. Bu nedenle, aşınırlar.
Sonuç olarak, entegrasyon testine daha fazla odaklanılmasıyla birlikte aşağıdaki şekil ortaya çıkabilir:
Bir piramit elmasa dönüşür. Önceki üç katmanı farklı bir boyutta görebilirsiniz. Birim katmanı ise kesilmiştir:
- Birim. Birim testlerini daha önce tanımladığınız şekilde yazın. Ancak, aşınmaya eğilimli olduklarından yalnızca en kritik vakalara öncelik verin ve bu vakaları ele alın.
- Entegrasyon. Tek birimlerin birleşimini test eden, bildiğiniz entegrasyon testleri.
- E2E. Bu katman, test piramidine benzer şekilde kullanıcı arayüzü testlerini yönetir. Yalnızca en kritik test senaryoları için E2E testi yazdığınızdan emin olun.
Petek testi
Spotify tarafından kullanıma sunulan ve test elmasına benzer ancak mikro hizmet tabanlı yazılım sistemleri için daha da özelleştirilmiş başka bir uyarlama da vardır. Test bal 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 benzetmedir. Küçük boyutları nedeniyle, mikro hizmetlerdeki en önemli karmaşıklık, hizmetin kendisinde değil, diğer hizmetlerle etkileşim biçimindedir. Bu nedenle, mikro hizmetler için test stratejisi öncelikle entegrasyon testlerine odaklanmalıdır.
Bu şekil bize petek şeklini hatırlattığı için bu adı verdik. Aşağıdaki katmanları içerir:
- Entegre testler. Spotify'ın makalesinde J. B. Rainsberger'ın bu katmanı tanımlamak için kullandığı ifadeyi kullanabiliriz: "Başka bir sistemin doğruluğuna bağlı olarak geçecek veya geçmeyecek bir test." Bu tür testlerin dikkate almanız gereken harici bağımlılıkları vardır. Bunun tam tersi olarak, sisteminiz diğer sistemleri bozan bir bağımlılık olabilir. Diğer benzetmelerdeki uçtan uca testlere benzer şekilde, bu testleri yalnızca en önemli durumlarda dikkatli bir şekilde kullanın.
- Entegrasyon testleri. Diğer uyarlamalara benzer şekilde bu katmana odaklanmanız gerekir. Bu test, hizmetinizin doğruluğunu daha izole bir şekilde ancak diğer hizmetlerle birlikte doğrulayan testleri içerir. Diğer bir deyişle, testler diğer bazı sistemleri de içerecek ve API testleri aracılığıyla etkileşim noktalarına odaklanacak.
- Uygulama ayrıntılarıyla ilgili testler. Bu testler, kodun doğal olarak izole edilmiş ve dolayısıyla kendi iç karmaşıklığına sahip bölümlerine odaklanan birim testlerine benzer.
Bu test stratejisi hakkında daha fazla bilgi edinmek istiyorsanız Martin Fowler'un test piramidini peteğe karşılaştıran yayınını ve Spotify'ın orijinal makalesini inceleyin.
Test kupası
Entegrasyon testlerine odaklanmanın tekrarlandığını görebilirsiniz. Ancak önceki makalede karşılaştığınız başka bir tür, teorik olarak test değildir ancak yine de bir test stratejisinde dikkate almanız gereken önemli bir unsurdur. Statik analiz, test piramidinde ve bugüne kadar gördüğünüz uyarlamaların çoğunda yer almıyor. Entegrasyon testlerine odaklanırken statik analizi dikkate alan test ödülü uyarlaması da vardır. Test ödülü, Guillermo Rauch'un daha önceki alıntısında yer alan ifadeden esinlenerek Kent C. tarafından geliştirildi. Dodds:
Test ödülü, testlerin ayrıntı düzeyini biraz farklı bir şekilde gösteren bir benzetmedir. Dört katmanı vardır:
- Statik analiz. Bu benzetmede önemli bir rol oynar ve yalnızca önceden belirtilen 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. Bunlar, en küçük biriminizin uygun şekilde test edilmesini sağlar ancak test kupası, bunları test piramidiyle aynı ölçüde vurgulamaz.
- Entegrasyon. Diğer uyarlamalarda olduğu gibi maliyeti ve daha yüksek güveni en iyi şekilde dengelediği için bu, ana odak noktasıdır.
- Kullanıcı arayüzü testleri. E2E ve görsel testler dahil olmak üzere, test piramidindeki rollerine benzer şekilde test kupasının en üstünde yer alırlar.
Test ödülü hakkında daha fazla bilgi edinmek için Kent C. Dodds'ın bu konuyla ilgili makalesini inceleyin.
Kullanıcı arayüzüne odaklanan diğer yaklaşımlar
Bu iyi bir başlangıç olsa da stratejinizi "piramit", "bal peteği" veya "elmas" olarak adlandırmanız fark etmez, eksik bir şeyler var. Test otomasyonu değerli olsa da manuel testin hâlâ önemli olduğunu unutmayın. Otomatik test, rutin görevleri hafifleterek kalite güvencesi mühendislerinin önemli alanlara odaklanmasını sağlar. Otomasyon, manuel testin yerini almak yerine onu tamamlamalıdır. Optimum sonuçlar için manuel testi otomasyonla entegre etmenin bir yolu var mı?
Test edilen dondurma külahı ve yengeç
Test piramidinin, kullanıcı arayüzüne odaklanan bu test yöntemlerine daha fazla odaklanan iki uyarlaması vardır. Her ikisi de yüksek güven avantajına sahiptir ancak testin daha yavaş yürütülmesi nedeniyle doğal olarak daha maliyetlidir.
İlki, test amaçlı buz konisi, ters piramide benziyor. 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. Bu durum genellikle geliştiricilerin test stratejisi hakkında yalnızca birkaç düşünceyle çalışmaya başladıkları projelerde ortaya çıkar. Ice kodu, anti-pattern olarak kabul edilir ve haklı olarak da öyledir. 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 vurgu yapar:
Bu test stratejisinin bir yönü daha vardır: Uygulamanızın düzgün çalıştığından ve iyi göründüğünden emin olur. Test yengeci, önceki makalede açıklanan görsel testin önemini vurgular. Bileşen ve API testine ayrılan entegrasyon testi daha da arka plana çekiliyor ve birim testi burada daha da ikincil bir rol oynuyor. Bu test stratejisiyle ilgili daha fazla bilgiyi test kralı hakkındaki makalede bulabilirsiniz.
Daha maliyetli olsalar da bu iki test stratejisinin yeri vardır: Ö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 kapsamlı bir test stratejisi fazla mühendislik gerektirebilir.
Bu iki test stratejisi daha maliyetli olsa da, daha az test gerektiren ve çok fazla karmaşıklığı kapsaması gerekmeyen küçük projelerde kullanılabilecekleri yerler vardır. Bu durumda, entegrasyon testine odaklanan tam kapsamlı bir test stratejisi gereksiz yere karmaşık olabilir.
Pratik tavsiye: Strateji oluşturalım.
Artık en yaygın test stratejileri hakkında bilgi sahibi oldunuz. Klasik test piramidiyle başladınız ve birçok uyarlamasını öğrendiniz. Artık bunları ürününüz için değerlendirmeniz ve projeniz için en uygun olana karar vermeniz gerekiyor. Bu sorunun cevabı, herkesin sevdiği "Buna bağlı" ifadesiyle başlamalıdır. Ancak bu, doğruluğunu etkilemez.
Açıklananlar arasından (hatta dışarıda bırakılanlar arasından) en uygun test stratejisini seçmek, uygulamanıza bağlıdır. Mimarinize, 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 normal bir durumdur. En önemli hedefinizin, ders kitaplarındaki bir tanım değil, kullanıcılarınıza hizmet etmek olduğunu unutmayın.
Gerçek dünyadaki testlerin ayrı ayrı ayrılması ve tanımlanması genellikle zordur. Martin Fowler bile birim testleri gibi durumlarda farklı tanımların olumlu yönünü vurgular. Justin Searls'ın tweet'inde belirttiği gibi:
[…] net sınırlar belirleyen, hızlı ve güvenilir şekilde çalışan ve yalnızca yararlı nedenlerle başarısız olan anlamlı testler yazın.
Justin Searls tarafından
Kullanıcıların karşılaşabileceği gerçek hataları bildiren testlere odaklanın ve amacınızdan uzaklaşmayın. Testler, yalnızca% 100 kapsam sağlamak veya hangi test türünün hangi yüzdesinin yazılacağı konusunda 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 hataları bildiren testlere odaklanın ve amacınızdan sapmayın. Testler, yalnızca% 100 kapsam sağlamak veya belirli bir test türünün ne kadarını yazmanız gerektiğiyle ilgili tartışmalara yol açmak için değil, kullanıcıya fayda sağlayacak şekilde tasarlanmalıdır.