Birim testleriyle sola kaydırma testi

Test, kodun beklendiği gibi çalışmasını sağlamaya yardımcı olur, ancak test oluşturma süresi ve çabası özellik geliştirme gibi diğer görevlerden zaman alır. Bu maliyetle testten maksimum değeri ayıklamak önemlidir. Bu makalede, birim testinin değerine ve sola kaydırmalı test stratejisine odaklanan DevOps test ilkeleri ele alınmaktadır.

Çoğu testi yazmak için kullanılan ayrılmış test ediciler ve birçok ürün geliştiricisi birim testi yazmayı öğrenmedi. Test yazmak çok zor veya çok fazla iş gibi görünebilir. Birim testi stratejisinin çalışıp çalışmadığı, kötü yazılmış birim testleriyle ilgili kötü deneyimler veya birim testlerinin işlevsel testlerin yerini alama korkusuyla ilgili şüpheler olabilir.

DevOps test stratejisi uygulamak için pragmatik olun ve ivme oluşturmaya odaklanın. Temiz bir şekilde yeniden düzenlenebilen yeni kod veya mevcut kod için birim testlerinde ısrar edebilirsiniz, ancak eski bir kod tabanının bazı bağımlılıklara izin vermek mantıklı olabilir. Ürün kodunun önemli bölümleri SQL kullanıyorsa, birim testlerinin bu katmanla dalga geçmek yerine SQL kaynak sağlayıcısına bağımlılık almasına izin vermek, ilerlemeye yönelik kısa vadeli bir yaklaşım olabilir.

DevOps kuruluşları büyüdükçe, liderlik süreçlerini geliştirmek daha kolay hale gelir. Değişikliğe karşı bazı dirençler olsa da Çevik kuruluşlar, kar paylarını açıkça ödeyen değişikliklere değer verir. Daha az hatayla daha hızlı test çalıştırmalarının vizyonunu satmak kolay olmalıdır, çünkü özellik geliştirme yoluyla yeni değer oluşturmaya yatırım yapmak için daha fazla zaman gerekir.

DevOps test taksonomisi

Test taksonomisi tanımlamak, DevOps test sürecinin önemli bir yönüdür. DevOps test taksonomisi, tek tek testleri bağımlılıklarına ve çalıştırma süresine göre sınıflandırır. Geliştiriciler, farklı senaryolarda kullanılacak doğru test türlerini ve işlemin farklı bölümlerinin hangi testleri gerektirdiğini anlamalıdır. Kuruluşların çoğu testleri dört düzeyde kategorilere ayırır:

• L0 ve L1 testleri , birim testleri veya test altındaki derlemedeki koda bağımlı olan testlerdir ve başka bir şey yoktur. L0, hızlı, bellek içi birim testlerinin geniş bir sınıfıdır.
• L2 , derlemeyi ve SQL veya dosya sistemi gibi diğer bağımlılıkları gerektirebilecek işlevsel testlerdir .
• L3 işlev testleri, test edilebilir hizmet dağıtımlarında çalıştırılır. Bu test kategorisi bir hizmet dağıtımı gerektirir, ancak anahtar hizmet bağımlılıkları için saptamaları kullanabilir.
• L4 testleri, üretime karşı çalışan kısıtlı bir tümleştirme testi sınıfıdır. L4 testleri tam ürün dağıtımı gerektirir.

Tüm testlerin her zaman çalıştırılması ideal olsa da, uygulanabilir değildir. Teams, DevOps işleminde her testin çalıştırıldığı yeri seçebilir ve işlemin önceki veya sonraki bölümlerinde farklı test türlerini taşımak için shift-left veya shift-right stratejilerini kullanabilir.

Örneğin, geliştiricilerin işlemeden önce her zaman L2 testlerini çalıştırması, L3 test çalıştırması başarısız olursa çekme isteğinin otomatik olarak başarısız olması ve L4 testlerinin başarısız olması durumunda dağıtımın engellenmesi beklenebilir. Belirli kurallar kuruluştan kuruluşa farklılık gösterebilir, ancak bir kuruluştaki tüm ekipler için beklentileri zorunlu tutma, herkesi aynı kalite vizyonu hedeflerine taşır.

Birim testi yönergeleri

L0 ve L1 birim testleri için katı yönergeler belirleyin. Bu testlerin çok hızlı ve güvenilir olması gerekir. Örneğin, bir derlemedeki L0 testi başına ortalama yürütme süresi 60 milisaniyeden az olmalıdır. Bir derlemedeki L1 testi başına ortalama yürütme süresi 400 milisaniyeden az olmalıdır. Bu düzeyde hiçbir test 2 saniyeyi aşmamalıdır.

Bir Microsoft ekibi, altı dakikadan kısa sürede paralel olarak 60.000'den fazla birim testi çalıştırır. Amaçları bu süreyi bir dakikadan kısa bir süreye düşürmektir. Ekip, birim testi yürütme süresini aşağıdaki grafik gibi araçlarla izler ve izin verilen süreyi aşan testlerde hataları kaydeder.

İşlevsel test yönergeleri

İşlevsel testler bağımsız olmalıdır. L2 testlerinin temel kavramı yalıtımdır. Düzgün yalıtılmış testler, çalıştıkları ortam üzerinde tam denetime sahip olduklarından herhangi bir sırayla güvenilir bir şekilde çalıştırılabilir. Durum, testin başında bilinmelidir. Bir test verileri oluşturup veritabanında bırakırsa, farklı bir veritabanı durumuna bağlı olan başka bir testin çalıştırılmasını bozabilir.

Kullanıcı kimliği gerektiren eski testler, kimliği almak için dış kimlik doğrulama sağlayıcılarını çağırmış olabilir. Bu uygulama çeşitli zorluklara neden olabilir. Dış bağımlılık güvenilir olmayabilir veya anlık olarak kullanılamayabilir ve test bozulabilir. Bu uygulama test yalıtımı ilkesini de ihlal eder çünkü bir test, diğer testler için beklenmeyen bir varsayılan duruma neden olan izin gibi bir kimliğin durumunu değiştirebilir. Test çerçevesi içinde kimlik desteğine yatırım yaparak bu sorunları önlemeyi göz önünde bulundurun.

DevOps test ilkeleri

Test portföyünü modern DevOps süreçlerine geçirmek için kaliteli bir vizyon ifade edin. Teams, DevOps test stratejisini tanımlarken ve uygularken aşağıdaki test ilkelerine uymalıdır.

Daha önce test etmek için sola kaydırma

Testlerin çalıştırılması uzun sürebilir. Projeler ölçeklendirildikçe, test sayıları ve türleri önemli ölçüde artar. Test paketlerinin tamamlanması saatler veya günler sürecek şekilde arttığında, son anda çalışana kadar daha uzağa itebilirler. Testlerin kod kalitesi avantajları, kod işlendikten çok sonra gerçekleştirilemez.

Uzun süre çalışan testler, araştırmak için zaman alan hatalar da üretebilir. Ekipler, özellikle sprint'lerin erken aşamalarında hatalara yönelik bir tolerans oluşturabilir. Bu tolerans, kod tabanı kalitesine ilişkin içgörü olarak test etme değerini baltalar. Kodun gönderilebilir olması için bilinmeyen miktarda teknik borcun ödenmesi gerektiğinden, uzun süre çalışan son dakika testleri sprint sonu beklentilerine öngörülemezlik de ekler.

Testi sola kaydırmanın amacı, işlem hattında daha önce test görevleri gerçekleştirerek kaliteyi yukarı akışa taşımaktır. Test ve süreç geliştirmelerinin birleşimiyle sola kaydırma, hem testlerin çalışması için gereken süreyi hem de döngünün ilerleyen bölümlerindeki hataların etkisini azaltır. Sola kaydırma, bir değişiklik ana dalla birleştirilmeden önce testlerin çoğunun tamamlanmasını sağlar.

Ekipler, kod kalitesini artırmak için belirli test sorumluluklarını değiştirmenin yanı sıra, son ürünü iyileştirmek için diğer test yönlerini DevOps döngüsünde sağa veya daha sonra kaydırabilir. Daha fazla bilgi için bkz . Üretimde test etmek için sağa kaydırma.

Testleri mümkün olan en düşük düzeyde yazma

Daha fazla birim testi yazın. En az dış bağımlılıkla testleri tercih edin ve derlemenin bir parçası olarak çoğu testi çalıştırmaya odaklanın. Derleme ve ilişkili testler bırakıldığında bir derleme için birim testleri çalıştırabilen paralel bir derleme sistemi düşünün. Bir hizmetin her yönünü bu düzeyde test etmek mümkün değildir, ancak daha ağır işlevsel testlerde aynı sonuçları üretebileceklerse daha hafif birim testleri kullanmak ilkedir.

Test güvenilirliğini hedefleme

Güvenilir olmayan bir testin sürdürülmesi kurumsal olarak pahalıdır. Böyle bir test, güvenle değişiklik yapmayı zorlaştırarak doğrudan mühendislik verimliliği hedefine karşı çalışır. Geliştiriciler her yerde değişiklik yapabilmeli ve hiçbir şeyin bozulmadığından hızla emin olmalıdır. Güvenilirlik için yüksek bir çubuk sağlayın. Kullanıcı arabirimi testlerinin kullanımını önerilmez, çünkü güvenilir olma eğilimindedirler.

Her yerde çalışabilen işlevsel testler yazma

Testler, testi etkinleştirmek için özel olarak tasarlanmış özel tümleştirme noktaları kullanabilir. Bu uygulamanın bir nedeni, ürünün kendisinde test edilebilirlik eksikliğidir. Ne yazık ki, bunlar gibi testler genellikle iç bilgiye bağlıdır ve işlevsel bir test açısından önemli olmayan uygulama ayrıntılarını kullanır. Bu testler, testleri çalıştırmak için gerekli gizli dizilere ve yapılandırmaya sahip ortamlarla sınırlıdır ve bu ortamlar genellikle üretim dağıtımlarını dışlar. İşlevsel testler yalnızca ürünün genel API'sini kullanmalıdır.

Test edilebilirlik için ürün tasarlama

Olgun bir DevOps sürecindeki kuruluşlar, bulut temposunda kaliteli bir ürün sunmanın ne anlama geldiğini tam olarak ele alır. İşlevsel testlere göre birim testinin lehine dengeyi güçlü bir şekilde değiştirmek, ekiplerin test edilebilirliği destekleyen tasarım ve uygulama seçimleri yapmasını gerektirir. Aynı farklı kodlama stilleri olduğu gibi, test edilebilirlik için iyi tasarlanmış ve iyi uygulanmış kodun ne olduğu hakkında farklı fikirler vardır. İlke, test edilebilirlik tasarımının tasarım ve kod kalitesi tartışmasının birincil parçası olması gerektiğidir.

Test kodunu ürün kodu olarak değerlendirin

Test kodunun ürün kodu olduğunu açıkça ifade etmek, test kodunun kalitesinin ürün kodu kadar gönderimde de önemli olduğunu açıkça gösterir. Ekipler test kodunu ürün koduna davrandıkları gibi ele almalı ve testlerin ve test çerçevelerinin tasarımına ve uygulanmasına aynı bakım düzeyini uygulamalıdır. Bu çaba, yapılandırmayı ve altyapıyı kod olarak yönetmeye benzer. Bir kod incelemesinin tamamlanması için test kodunu dikkate alması ve ürün koduyla aynı kalite çubuğunda tutması gerekir.

Paylaşılan test altyapısını kullanma

Güvenilir kalite sinyalleri oluşturmak için test altyapısını kullanmak için çıtayı düşür. Testi tüm ekip için paylaşılan hizmet olarak görüntüleyin. Birim test kodunu ürün koduyla birlikte depolayın ve ürünle birlikte oluşturun. Derleme işleminin bir parçası olarak çalışan testler, Azure DevOps gibi geliştirme araçları altında da çalıştırılmalıdır. Testler yerel geliştirmeden üretime kadar her ortamda çalıştırılabilirse, ürün koduyla aynı güvenilirliğe sahiptir.

Kod sahiplerini testden sorumlu hale getirme

Test kodu, depodaki ürün kodunun yanında bulunmalıdır. Kodun bir bileşen sınırında test edilmesi için, bileşen kodunu yazan kişiye test için sorumluluk gönderme. Bileşeni test etmek için başkalarına güvenmeyin.

Örnek olay incelemesi: Birim testleriyle sola kaydırma

Bir Microsoft ekibi, eski test paketlerini modern, DevOps birim testleri ve sola kaydırma işlemiyle değiştirme kararı aldı. Ekip, aşağıdaki grafikte gösterildiği gibi üç haftalık sprint'lerde ilerleme durumunu izlemiştir. Grafik, 126 haftada 42 sprint'i veya yaklaşık iki buçuk yıllık çabayı temsil eden 78-120 sprint'leri kapsar.

Ekip sprint 78'de 27 bin eski testle başladı ve S120'de sıfır eski teste ulaştı. Bir dizi L0 ve L1 birim testi, eski işlevsel testlerin çoğunun yerini aldı. Yeni L2 testleri bazı testlerin yerini aldı ve eski testlerin çoğu silindi.

tamamlanması iki yılı aşan bir yazılım yolculuğunda sürecin kendisinden öğrenebileceğiniz çok şey vardır. Genel olarak, test sistemini iki yıl boyunca tamamen yeniden deneme çabası büyük bir yatırımdı. Her özellik ekibi işi aynı anda yapmadı. Kuruluş genelindeki birçok ekip her sprint'e zaman yatırdı ve bazı sprint'lerde bu, ekibin yaptığı işlemlerin çoğuydu. Vardiyanın maliyetini ölçmek zor olsa da, takımın kalite ve performans hedefleri için pazarlık edilemez bir gereksinimdi.

Başlarken

Başlangıçta ekip, TRA testleri olarak adlandırılan eski işlevsel testleri tek başına bıraktı. Ekip, geliştiricilerin özellikle yeni özellikler için birim testleri yazma fikrini satın almasını istedi. Odak, L0 ve L1 testleri yazmayı mümkün olduğunca kolaylaştırmaktı. Ekibin önce bu özelliği geliştirmesi ve ivme oluşturması gerekiyordu.

Yukarıdaki grafikte, ekip birim testleri yazmanın avantajını gördüğünden birim testi sayısının erken artmaya başladığı gösterilmektedir. Birim testlerinin bakımı daha kolaydı, daha hızlı çalıştırıldı ve daha az hata oluştu. Çekme isteği akışında tüm birim testlerini çalıştırmak için destek almak kolaydı.

Ekip, sprint 101'e kadar yeni L2 testleri yazmaya odaklanmadı. Bu arada, TRA test sayısı Sprint 78'den Sprint 101'e 27.000'den 14.000'e düştü. Yeni birim testleri bazı TRA testlerinin yerini aldı, ancak bunların yararlılıklarının ekip analizine göre çoğu basitçe silindi.

Kaynak ağaçta daha fazla test bulunduğundan ve grafiğe eklendiğinden, 110. sprint'te TRA testleri 2100'den 3800'e atladı. Testlerin her zaman çalıştığı, ancak düzgün izlenmediği ortaya çıktı. Bu bir kriz değildi, ama dürüst olmak ve gerektiğinde yeniden değerlendirmek önemliydi.

Daha hızlı hale geliyor

Ekip son derece hızlı ve güvenilir bir sürekli tümleştirme (CI) sinyaline sahip olduktan sonra ürün kalitesi için güvenilir bir gösterge haline geldi. Aşağıdaki ekran görüntüsünde çekme isteğinin ve CI işlem hattının çalışması ve çeşitli aşamalardan geçmek için gereken süre gösterilmektedir.

60.000 birim testi çalıştırmayı içeren çekme isteğinden birleştirmeye gitmek yaklaşık 30 dakika sürer. Kod birleştirmeden CI derlemesine kadar yaklaşık 22 dakikadır. CI,SelfTest'ten gelen ilk kalite sinyali yaklaşık bir saat sonra gelir. Ardından, ürünün çoğu önerilen değişiklikle test edilir. Merge'ten SelfHost'a iki saat içinde tüm ürün test edilir ve değişiklik üretime girmeye hazırdır.

Ölçümleri kullanma

Ekip, aşağıdaki örneğe benzer bir karne izler. Karne yüksek düzeyde iki ölçüm türünü izler: Sağlık veya borç ve hız.

Canlı site durumu ölçümleri için ekip algılama süresini, azaltma süresini ve bir ekibin taşıdığı onarım öğelerinin sayısını izler. Onarım öğesi, benzer olayların tekrarlanmasını önlemek için ekibin canlı bir site geçmişe dönük değerlendirmesinde tanımlaması gereken bir çalışmadır. Karne ayrıca ekiplerin onarım öğelerini makul bir zaman çerçevesi içinde kapatıp kapatmadığını da izler.

Mühendislik durumu ölçümleri için ekip, geliştirici başına etkin hataları izler. Bir ekibin geliştirici başına beşten fazla hatası varsa, ekibin yeni özellik geliştirmeden önce bu hataları düzeltmeye öncelik vermesi gerekir. Ekip ayrıca eskiyen hataları güvenlik gibi özel kategorilerde de izler.

Mühendislik hızı ölçümleri, sürekli tümleştirme ve sürekli teslim (CI/CD) işlem hattının farklı bölümlerinde hızı ölçer. Genel hedef, DevOps işlem hattının hızını artırmaktır: Bir fikirden başlayarak kodu üretime alma ve müşterilerden verileri geri alma.

Sonraki adımlar

• Öğrenme yolu: Azure DevOps ile uygulama oluşturma
• Sürekli tümleştirmeyi kullanma
• Üretimde test etmek için sağa kaydırma
• Sahteler Saplama Değil