Service Fabric'te durum bilgisi olan hizmetleri test etme

Bu makale, Service Fabric Durum Bilgisi Olan Hizmetler'de birim testi yapma kavramlarını ve uygulamalarını kapsar. Uygulama kodunun birden çok farklı bağlam altında etkin bir şekilde çalışması nedeniyle Service Fabric içindeki birim testi kendi dikkate alınmasını hak eder. Bu makalede, uygulama kodunun çalıştırabileceği farklı bağlamların her biri kapsamında olduğundan emin olmak için kullanılan uygulamalar açıklanmaktadır.

Birim testi ve sahte oluşturma

Bu makale bağlamında birim testi, MSTest veya NUnit gibi bir test çalıştırıcısı bağlamında yürütülebilen otomatikleştirilmiş testtir. Bu makaledeki birim testleri veritabanı veya RESTful gibi uzak bir kaynak üzerinde işlem gerçekleştirmez. Bu uzak kaynaklar sahte olmalıdır. Bu makale bağlamında sahte işlem, uzak kaynaklar için dönüş değerlerini taklit eder, kaydeder ve denetler.

Service Fabric ile ilgili dikkat edilmesi gerekenler

Service Fabric durum bilgisi olan bir hizmetin birim testinin dikkate alınması gereken birkaç nokta vardır. İlk olarak, hizmet kodu birden çok düğümde ancak farklı roller altında yürütülür. Birim testleri, tam kapsam elde etmek için her rol altındaki kodu değerlendirmelidir. Farklı roller Birincil, Etkin İkincil, Boşta İkincil ve Bilinmiyor rolleridir. Service Fabric bu rolün geçersiz veya null hizmet olduğunu düşündüğü için Hiçbiri rolü genellikle herhangi bir özel kapsama ihtiyaç duymaz. İkinci olarak, her düğüm belirli bir noktada rolünü değiştirir. Tam kapsam elde etmek için kod yürütme yollarının rol değişiklikleriyle test edilmesi gerekir.

Durum bilgisi olan birim testi hizmetleri neden?

Durum bilgisi olan birim testi hizmetleri, geleneksel uygulama veya etki alanına özgü birim testi tarafından yakalanması gerekmeyen bazı yaygın hataların ortaya çıkarılmasına yardımcı olabilir. Örneğin, durum bilgisi olan hizmetin bellek içi durumu varsa, bu tür testler bu bellek içi durumun her çoğaltmada eşitlenmiş olarak tutulduğunu doğrulayabilir. Bu test türü, durum bilgisi olan bir hizmetin Service Fabric düzenlemesi tarafından geçirilen iptal belirteçlerine uygun şekilde yanıt verdiğini de doğrulayabilir. İptaller tetiklendiğinde, hizmetin uzun süre çalışan ve/veya zaman uyumsuz işlemleri durdurması gerekir.

Yaygın uygulamalar

Aşağıdaki bölümde durum bilgisi olan bir hizmeti birim testi için en yaygın yöntemler hakkında öneriler verilmektedir. Ayrıca, bir sahte katmanın Service Fabric düzenleme ve durum yönetimiyle yakından uyumlu hale getirmek için sahip olması gerekenleri de önerir. ServiceFabric.Mocks 3.3.0 veya sonraki bir sürümden itibaren önerilen sahte işlevselliği sağlayan ve aşağıda açıklanan uygulamaları izleyen kitaplıklardan biridir.

Düzenleme

Birden çok hizmet örneği kullanma

Birim testleri durum bilgisi olan bir hizmetin birden çok örneğini yürütmelidir. Bu, Service Fabric'in hizmetinizi farklı düğümler arasında çalıştıran birden çok çoğaltma sağladığı kümede gerçekleşen işlemlerin benzetimini gerçekleştirir. Ancak bu örneklerin her biri farklı bir bağlam altında yürütülecektir. Test çalıştırılırken, her örnek kümede beklenen rol yapılandırmasına sahip olmalıdır. Örneğin, hizmetin hedef çoğaltma boyutunun 3 olması bekleniyorsa, Service Fabric farklı düğümlerde üç çoğaltma sağlar. Bunlardan biri birincil, diğeri de Etkin İkincil'in.

Çoğu durumda, hizmet yürütme yolları bu rollerin her biri için biraz farklılık gösterir. Örneğin, hizmetin Etkin İkincil'den gelen istekleri kabul etmemesi gerekiyorsa, hizmetin ikincil bir istek üzerinde denendiğini belirten bilgilendirici bir özel durum oluşturmak için bu durum için bir denetimi olabilir. Birden çok örneğin olması bu durumun test edilmesine olanak tanır.

Ayrıca, birden çok örneğe sahip olmak, testlerin rol değişikliklerine rağmen yanıtların tutarlı olduğunu doğrulamak için bu örneklerin her birinin rollerini değiştirmesine olanak tanır.

Durum yöneticisini taklit

State Manager uzak kaynak olarak kabul edilmeli ve bu nedenle sahte olmalıdır. Durum yöneticisinin sahtesini oluştururken, durum yöneticisine kaydedilenlerin okunabilmesi ve doğrulanması için izlenmesi için bazı temel alınan bellek içi depolama alanı olması gerekir. Bunu yapmanın basit bir yolu, Güvenilir Koleksiyon türlerinin her birinin sahte örneklerini oluşturmaktır. Bu sahteler içinde, söz konusu koleksiyonda gerçekleştirilen işlemlerle yakından uyumlu bir veri türü kullanın. Aşağıda, her güvenilir koleksiyon için önerilen bazı veri türleri yer alır

• IReliableDictionary<TKey, TValue> -> System.Collections.Concurrent.ConcurrentDictionary<TKey, TValue>
• IReliableQueue<T> -> System.Collections.Generic.Queue<T>
• IReliableConcurrentQueue<T> -> System.Collections.Concurrent.ConcurrentQueue<T>

Birçok State Manager Örneği, tek depolama alanı

Daha önce belirtildiği gibi, State Manager ve Reliable Collections uzak kaynak olarak ele alınmalıdır. Bu nedenle, bu kaynakların birim testlerinin içinde sahte olması ve sahte olması gerekir. Ancak durum bilgisi olan bir hizmetin birden çok örneğini çalıştırırken, her sahte durum yöneticisini farklı durum bilgisi olan hizmet örnekleri arasında eşitlenmiş durumda tutmak zor olacaktır. Durum bilgisi olan hizmet kümede çalışırken, Service Fabric her ikincil çoğaltmanın durum yöneticisinin birincil çoğaltmayla tutarlı kalmasını sağlar. Bu nedenle, testlerin rol değişikliklerinin benzetimini yapabilmesi için aynı şekilde davranması gerekir.

Bu eşitlemenin başarılabilmesinin basit bir yolu, her Güvenilir Koleksiyona yazılan verileri depolayan temel nesne için tekil bir desen kullanmaktır. Örneğin, durum bilgisi olan bir hizmet bir IReliableDictionary<string, string>kullanıyorsa. Sahte durum yöneticisi bir sahte değerini IReliableDictionary<string, string>döndürmelidir. Bu sahte, yazılan anahtar/değer çiftlerini izlemek için bir ConcurrentDictionary<string, string> kullanabilir. , ConcurrentDictionary<string, string> hizmete geçirilen durum yöneticilerinin tüm örnekleri tarafından kullanılan tekil olmalıdır.

İptal belirteçlerini izleme

İptal belirteçleri, durum bilgisi olan hizmetlerin önemli ancak yaygın olarak göz ardı edilen yönlerindendir. Service Fabric durum bilgisi olan bir hizmet için birincil çoğaltma başlattığında bir iptal belirteci sağlanır. Bu iptal belirteci, kaldırıldığında veya farklı bir role indirgendiğinde hizmete sinyal vermek için tasarlanmıştır. Service Fabric'in rol değiştirme iş akışını tamamlayabilmesi için durum bilgisi olan hizmetin uzun süre çalışan veya zaman uyumsuz işlemleri durdurması gerekir.

Birim testleri çalıştırılırken, test yürütmesi sırasında RunAsync, ChangeRoleAsync, OpenAsync ve CloseAsync için sağlanan tüm iptal belirteçleri tutulmalıdır. Bu belirteçleri tutmak testin bir hizmet kapatma veya indirgeme simülasyonu oluşturmasına ve hizmetin uygun şekilde yanıt verdiğini doğrulamasına olanak sağlar.

Sahte uzak kaynaklarla uçtan uca test etme

Birim testleri, durum bilgisi olan hizmetin durumunu mümkün olduğunca değiştirebilen uygulama kodunun büyük bir kısmını yürütmelidir. Testlerin doğası gereği uçtan uca olması önerilir. Mevcut olan tek sahte öğeler, uzak kaynak etkileşimlerini kaydetmek, benzetmek ve/veya doğrulamaktır. Bu Durum Yöneticisi ve Güvenilir Koleksiyonlar ile etkileşimleri içerir. Aşağıdaki kod parçacığı, uçtan uca testi gösteren bir test için gherkin örneğidir:

	Given stateful service named "fabric:/MyApp/MyService" is created
	And a new replica is created as "Primary" with id "111"
	And a new replica is created as "IdleSecondary" with id "222"
    And a new replica is created as "IdleSecondary" with id "333"
	And all idle secondary replicas are promoted to active secondary
	When a request is made to add the an employee "John Smith"
    And the active secondary replica "222" is promoted to primary
    And a request is made to get all employees
	Then the request should should return the "John Smith" employee

Bu test, bir çoğaltmada yakalanan verilerin birincil çoğaltmaya yükseltildiğinde ikincil çoğaltma için kullanılabilir olduğunu onaylar. Güvenilir bir koleksiyonun çalışan verileri için yedekleme deposu olduğunu varsayarsak, bu testle yakalanabilecek olası Aa hatası, uygulama kodunun yeni çalışanı kaydetmek için işlemde yürütülmemesidir CommitAsync . Bu durumda, çalışanları almak için yapılan ikinci istek, ilk istek tarafından eklenen çalışanı geri döndürmez.

Davranı

Service Fabric çoğaltma düzenlemesi takliti

Birden çok hizmet örneğini yönetirken testler bu hizmetleri Service Fabric düzenlemesi ile aynı şekilde başlatıp yok etmelidir. Örneğin, yeni bir birincil çoğaltmada bir hizmet oluşturulduğunda, Service Fabric CreateServiceReplicaListener, OpenAsync, ChangeRoleAsync ve RunAsync'i çağırır. Yaşam döngüsü olayları aşağıdaki makalelerde belgelenmiştir:

• Durum Bilgisi Olan Hizmet Başlatma
• Durum Bilgisi Olan Hizmet Kapatma
• Durum Bilgisi Olan Hizmet Birincil Değiştirmeleri

Çoğaltma rolü değişikliklerini çalıştırma

Birim testleri, hizmet örneklerinin rollerini Service Fabric düzenlemesi ile aynı şekilde değiştirmelidir. Rol durumu makinesi aşağıdaki makalede belgelenmiştir:

Çoğaltma Rolü Durum Makinesi

Rol değişikliklerinin benzetimi testin daha kritik yönlerinden biridir ve çoğaltmanın durumunun birbiriyle tutarlı olmadığı sorunları ortaya çıkarabilir. Tutarsız çoğaltma durumu, bellek içi durumu statik veya sınıf düzeyi örnek değişkenlerinde depolama nedeniyle oluşabilir. Buna örnek olarak iptal belirteçleri, sabit listeleri ve yapılandırma nesneleri/değerleri verilebilir. Bu, rol değişikliğinin gerçekleşmesine izin vermek için hizmetin RunAsync sırasında sağlanan iptal belirteçlerine saygısını da sağlar. Rol değişikliklerini simüle etmek, RunAsync'in birden çok kez çağrılmasına izin vermek için kod yazılmazsa ortaya çıkabilecek sorunları da ortaya çıkarır.

İptal belirteçlerini iptal etme

RunAsync'e sağlanan iptal belirtecinin iptal edildiği birim testleri olmalıdır. Bu, testin hizmetin düzgün bir şekilde kapatıldığını doğrulamasını sağlar. Bu kapatma sırasında uzun süre çalışan veya zaman uyumsuz işlemler durdurulmalıdır. Bir hizmette var olabilecek uzun süre çalışan bir işlem örneği, Güvenilir Kuyrukta iletileri dinleyen işlemdir. Bu, doğrudan RunAsync veya bir arka plan iş parçacığı içinde bulunabilir. Bu iptal belirteci iptal edilirse uygulama, işlemden çıkmak için mantık içermelidir.

Durum bilgisi olan hizmetler yalnızca birincil sunucuda bulunması gereken herhangi bir önbellek veya bellek içi durumu kullanıyorsa, şu anda atılmalıdır. Bu, düğüm daha sonra yeniden birincil duruma gelirse bu durumun tutarlı olmasını sağlamaktır. İptal testi, testin bu durumun düzgün şekilde atıldığından emin olmasını sağlar.

Birden çok çoğaltmaya yönelik istekleri yürütme

Onay testleri farklı çoğaltmalarda aynı isteği yürütmelidir. Rol değişiklikleriyle eşlendiğinde tutarlılık sorunları ortaya çıkarılabilir. Örnek bir test aşağıdaki adımları gerçekleştirebilir:

1. Geçerli birincile karşı yazma isteği yürütme
2. Geçerli birincile karşı 1. adımda yazılan verileri döndüren bir okuma isteği yürütme
3. İkincil bir birincile yükseltin. Bu, geçerli birincili ikincil olarak da indirgemelidir
4. 2. adımdaki aynı okuma isteğini yeni ikincil sunucuya karşı yürütür.

Son adımda test, döndürülen verilerin tutarlı olduğunu onaylayabilir. Bunun ortaya çıkarabileceği olası bir sorun, hizmet tarafından döndürülen verilerin bellekte olması ancak sonunda güvenilir bir koleksiyon tarafından yedeklenmiş olmasıdır. Bu bellek içi veriler, güvenilir koleksiyondakilerle düzgün bir şekilde eşitlenmemiş olabilir.

Bellek içi veriler genellikle güvenilir bir koleksiyonda bulunan verilerin ikincil dizinlerini veya toplamalarını oluşturmak için kullanılır.

Iddia

Yanıtların çoğaltmalar arasında eşleştiğinden emin olun

Birim testleri, belirli bir istek için verilen yanıtın birincil çoğaltmaya geçtikten sonra birden çok çoğaltmada tutarlı olduğunu onaylamalıdır. Bu, yanıtta sağlanan verilerin güvenilir bir koleksiyon tarafından yedeklenmediği veya bu verileri çoğaltmalar arasında eşitleme mekanizması olmadan bellek içinde tutulduğu olası sorunları ortaya verebilir. Bu, Service Fabric yeniden dengeledikten veya yeni bir birincil çoğaltmaya yük devrettikten sonra hizmetin tutarlı yanıtları geri göndermesini sağlar.

Hizmetin iptale saygılı olduğunu doğrulayın

bir iptal belirteci iptal edildiğinde sonlandırılması gereken uzun süre çalışan veya zaman uyumsuz işlemlerin, iptal işleminden sonra gerçekten sonlandırıldıkları doğrulanmalıdır. Bu, çoğaltmanın rolleri değiştirmesine rağmen, birincil olmayan çoğaltmada çalışmaya devam etmek üzere tasarlanmamış işlemlerin geçiş tamamlanmadan durmasını sağlar. Bu durum, böyle bir işlemin Service Fabric'ten gelen rol değişikliğini veya kapatma isteğinin tamamlanmasını engellemesi sorunlarını da ortaya çıkarır.

Hangi çoğaltmaların isteklere hizmet etmesi gerektiğini doğrulama

Bir istek birincil olmayan bir çoğaltmaya yönlendirilirse testler beklenen davranışı onaylamalıdır. Service Fabric, ikincil çoğaltmaların istekleri sunabilmesini sağlar. Ancak, güvenilir koleksiyonlara yazma işlemleri yalnızca birincil çoğaltmadan gerçekleşebilir. Uygulamanız yalnızca birincil çoğaltmaların isteklere hizmet etmeyi amaçlıyorsa veya isteklerin yalnızca bir alt kümesi ikincil bir tarafından işlenebilirse, testler hem pozitif hem de negatif durumlar için beklenen davranışı onaylamalıdır. İstek olan negatif durum, isteği işlememesi gereken bir çoğaltmaya yönlendirilir ve pozitif durum tam tersidir.

Sonraki adımlar

Durum bilgisi olan test hizmetlerini nasıl birleştireceğinizi öğrenin.