Örneklerle Sözleşme Testine Giriş

introduction contract testing with examples

Bu Sözleşme Sözleşme Testi öğreticisi, Tüketici Odaklı Sözleşme Testinin ne olduğunu, nasıl çalıştığını ve test stratejinizde neden kullanmanız gerektiğini açıklar:

Sözleşme Testi nedir?

Tüketici Odaklı Sözleşme Testi, sola kaydırmayı gerçekten sağlayan bir API testi biçimidir. Kullandığımız sözleşme aracı Pact.io ve daha sonra bu eğitim dizisinde öğreneceğiz.

Sözleşme testi, neyin geçildiğini test etmek ve iade edilenin 'sözleşme' ile eşleşip eşleşmediğini görmek için iki uygulama arasındaki entegrasyonu bağımsız olarak doğrulama yöntemidir.

Sözleşme testleri, çevik bir ortamda çalışan bir mikro hizmet mimarisine iyi uyum sağlar. Bu nedenle örnekler bu ortamda çalışırken edindiğimiz deneyime dayanacaktır.

Ne öğreneceksin:

• Bu Sözleşme Testi Serisindeki Öğreticilerin Listesi
• Tüketici Odaklı Sözleşme Testi
  • O nasıl çalışır
  • Görev ve Sorumluluklar
• Sözleşme Testi ve Entegrasyon Testi
  • Bazı Avantajlar (Henüz satılmadıysanız)
  • Sıkça Sorulan Sorular
• Sürekli Entegrasyon
• Sonuç
  • Önerilen Kaynaklar

Bu Sözleşme Testi Serisindeki Öğreticilerin Listesi

Öğretici 1: Örneklerle Sözleşme Testine Giriş (Bu Eğitici)
Öğretici # 2: JavaScript'te Tüketici Anlaşması Testi Nasıl Yazılır
Öğretici 3: Pact Broker'a Pact Sözleşmesi Nasıl Yayınlanır
Eğitim 4: Pact CLI ile Pact Sözleşmesini ve Sürekli Dağıtımı Doğrulayın

Tüketici Odaklı Sözleşme Testi

Başlangıç ​​noktası, testleriniz için sözleşmeyi oluşturan API belgelerinizdir, bu noktada genellikle geliştirme ekipleri API belgesini alır ve wiki belgesine (veya kuruluşunuzda hangi biçime sahipse, Word Belgesi gibi) göre geliştirir.

Örneğin, Ön ucun Team Krypton tarafından geliştirildiği ve API'nin Team Thoron tarafından geliştirildiği bir Web Uygulaması. Proje, gereksinimlerin sunulduğu ve ekipler arasında kararlaştırıldığı bir başlangıç ​​toplantısı ile başlar.

Her ekip gereksinimleri alır ve hikayeleri rafine ederek iş yığını oluşturmaya başlar. Geliştirme, kullanıcı hikayelerinin ardından her iki takımda da başlar, daha sonraki sprintler için entegrasyon testi kalır. Team Krypton hata senaryolarıyla ilgili ek gereksinimler buldukça, API belgeleri buna göre güncellenir.

Belgelere dayalı olarak güncellenmiş senaryolarla ilgili olarak Team Thoron tarafından test senaryoları eklenir.

Zaten bu süreçte birkaç kusur görebiliyoruz ve iyi şanslar için birkaç tane daha ekledim:

1. API belgesi değişiklikleri etkili bir şekilde iletilemeyebilir.
2. Ön uç ekibi, arka uç hizmetini devre dışı bırakır ve bunun tersi de geçerlidir.
3. Arka uç ekibi, belgelere dayalı entegrasyon testi senaryoları oluşturur.
4. Entegrasyon ortamı, tam entegrasyonun test edildiği ilk zamandır.
5. Entegrasyon ortamında üretime göre farklı API sürümü.

Tüketici odaklı sözleşme testinin iki tarafı vardır, yani tüketici ve sağlayıcı. Mikro hizmetlerde test etme hakkındaki geleneksel düşüncenin tersine döndüğü yer burasıdır.

Tüketici talep ve beklenen yanıt dahil olmak üzere senaryoların sorumlusudur. Bu takip etmenizi sağlar Yatak Kanunu API'nizin neyi kabul edebileceği konusunda esnek, ancak gönderilenlerde muhafazakar olmanız gerektiğini belirtir. Hayır kusurlara geri dönersek. 1, 3 ve 4, dokümantasyon değişiklikleri tüketici tarafından yönlendirilir.

Örneğin, Team Thoron'un bir dizi alanını boş değerleri kabul etmeyecek şekilde değiştirdiği durumda, tüketici testleri değişikliği yansıtmaz ve bu nedenle başarısız olur. Ya da en azından Krypton Takımında değişiklikler yapılana kadar.

(resim kaynak )

Sağlayıcı Tüketici tarafından sağlanan senaryoları 'geliştirme' ortamına göre doğrular. Bu, mikro hizmetlerinizin Paralel Değişim API işlevselliğini genişletmeniz ve ardından yeni bir sürüme geçmeniz gerektiğini belirtir. Kusur no. 2, genellikle arka uç ekipleri tarafından kendi test gereksinimleri için oluşturulan taslaklar, artık tüketici senaryolarına dayanabilir. Pact Saplama Sunucusu .

İki tarafın bağlayıcı unsuru, ekipler arasında paylaşılması gereken “sözleşmedir”. Anlaşma, sözleşme adı verilen sözleşmelerin paylaşılmasına olanak sağlayan bir platform sağlar. Pact Broker (ile yönetilen bir hizmet olarak mevcuttur Pactflow.io ).

Komisyoncu tüketici senaryolarının çıktılarını depolar. Sözleşme daha sonra aracıda API sürümüyle birlikte saklanır. Bu, API'nin birden çok sürümüne karşı test yapılmasını sağlar, böylece uyumluluk, 5 numaralı kusurda vurgulandığı gibi, sürümden önce doğrulanabilir.

Eski platformlarda Pact Broker'a ek bir fayda, tüketicilerin görünürlüğüdür. Tüm tüketiciler API yazarları tarafından bilinmemektedir, özellikle de nasıl tüketildiği değil.

Özellikle iki API sürümünün desteklendiği bir duruma atıfta bulunarak, sürüm 1 (V1) içinde API'nin neden olduğu bir veri sorunu vardı. kirli veriler veritabanında.

Değişiklik API'nin V1'inde uygulandı ve üretime gönderildi, ancak tüketici veri sorununa neden olan formata güvenerek API ile entegrasyonunu bozdu.

O nasıl çalışır

Yukarıdaki örnek kimlik doğrulama akışını gösterir, web hizmeti hassas verilere erişmek için kullanıcıların kimlik doğrulaması yapmasını gerektirir. Web hizmeti, bir kullanıcı adı ve parola kullanarak bir belirteç oluşturmak için API'ye bir istek gönderir. API, kimlik doğrulama başlığı olarak veri isteğine eklenen bir taşıyıcı belirteci döndürür.

Tüketici testi, gövdeyi kullanıcı adı ve parola ile ileterek bir belirteç için bir POST isteği oluşturur.

Test sırasında, oluşturduğunuz isteği doğrulayan ve bu örnekte belirteç değerini içeren beklenen yanıtla birlikte bir sahte sunucu döndürülür.

Tüketici testinin çıktısı bir anlaşma sözleşmesi dosyası oluşturur. Bu, pact broker'da sürüm 1 olarak saklanacaktır.

Daha sonra sağlayıcı, sürüm 1'i anlaşma aracısından çeker ve talebin ve yanıtın tüketici gereksinimleriyle eşleştiğini doğrulayarak bu talebi kendi yerel ortamlarında yeniden oynatır.

Görev ve Sorumluluklar

Kalite Güvencesi (QA) / Test Cihazı: Pact.io kullanarak sözleşmeler oluşturmak ve test senaryolarını oluşturmak için BA ile birlikte çalışmak.

Geliştirici: Testlerin oluşturulması ve Sürekli Entegrasyonda (CI) uygulanması için API'nin sarmalanmasına yardımcı olma konusunda QA ile eşleştirme.

İş Analisti (BA): Senaryolar oluşturmak ve etkilenen tarafları doğrulamak için mimarla birlikte çalışmak.

Çözüm Mimarı (Kuruluşunuzda bulunmayabilir): API değişikliklerini harekete geçirmek ve uygulama konusunda BA ile koordinasyon sağlamak, ayrıca değişiklikleri tüketicilere iletmek (kiminle ilgili olabileceğini anlamak için Pact Broker'ı kullanmak).

Sürüm Yönetimi: (Evet, bunun eski moda olduğunu biliyorum, ancak benim dünyamda hala var): Sözleşmeli test kapsamı nedeniyle değişikliklerin başarılı bir şekilde yayınlanacağına dair güven ile dolduruldu.

Bütün takım: Sürümlerin Pact CLI aracı ile üretime aktarılıp aktarılamayacağını belirlemek için sonuçları doğrulayın, Dağıtabilir miyim .

xbox one için vr var mı

Sözleşme Testi ve Entegrasyon Testi

Sistemin üretim ortamına yükseltilmeden önce çalışıp çalışmadığını doğrulamak için entegrasyon testinin var olması gerekir, ancak senaryolar önemli ölçüde azaltılabilir.

Bunun etkisi şunlar olabilir:

• Entegrasyon ortamına yayınlamadan önce daha hızlı geri bildirim.
• Entegrasyon ortamının istikrarına daha az güven.
• Birden çok API sürümünü destekleyen daha az ortam.
• Entegrasyon sorunları nedeniyle azaltılmış kararsız ortam örnekleri.

İlk olarak, sözleşme testi entegrasyon testinin yerini almaz. Ancak muhtemelen mevcut entegrasyon testi senaryolarınızdan bazılarının yerini alabilir, sola kaydırabilir ve yazılım geliştirme yaşam döngünüz için daha hızlı geri bildirim sağlar.

Entegrasyon testinde, ortam mimarisi, dağıtım süreci vb. Gibi API'nin yaşadığı bağlamı doğrulayacaksınız.

Bu nedenle, yapılandırmayı onaylayacak temel test senaryolarını çalıştırmak istiyorsunuz, Örneğin, api sürümü için durum denetimi uç noktası. Ayrıca 200 yanıt vererek konuşlandırmanın başarılı olup olmadığını kanıtlıyor.

Sözleşme testinde, API yapısı, içerik (örn. Alan değerleri, anahtarlar var) ve hata yanıtlarıyla ilgili uç durumları içeren API özelliklerini test edersiniz. Örneğin, API boş değerleri işliyor mu yoksa API yanıtından çıkarılıyor mu (başka bir gerçek örnek).

Bazı Avantajlar (Henüz satılmadıysanız)

Aşağıda, daha geniş bir işletmeye sözleşme testi satarken yararlanılacak bazı avantajlar listelenmiştir:

• Daha hızlı yazılım dağıtımı
• Tek bir gerçeğin kaynağı
• Tüm tüketicilerin görünürlüğü
• Farklı API sürümlerine karşı test kolaylığı.

Sıkça Sorulan Sorular

İnsanları sözleşme testini benimsemeye ikna etmeye çalışırken sorulan bazı genel sorular şunlardır:

S # 1) Zaten% 100 test kapsamına sahibiz, bu yüzden buna ihtiyacımız yok.

Cevap: Bu imkansız, ancak kontratlı testin test kapsamından başka birçok faydası var.

S # 2) API değişikliklerini bildirmek Çözüm Mimarı'nın sorumluluğundadır.

Cevap: Kalite tüm ekibin sorumluluğundadır.

S # 3) API ekibi için neden test senaryoları oluşturuyoruz?

Cevap: API ekibi web hizmetinin nasıl çalıştığını bilmiyor, öyleyse neden orada sorumluluk alsın?

S # 4) Uçtan uca testlerimiz, diğer entegrasyon noktaları da dahil olmak üzere, baştan sona tüm akışı kapsar.

Cevap: Tam olarak neden testleri bir şeyi test etmek için bölüyoruz ve nasıl çalıştığını bilmediğiniz bir sistemin uçtan uca akışını test etmek sizin sorumluluğunuz değil.

S # 5) Testler hangi takımın havuzunda yaşıyor?

Cevap: Her ikisi de. Depolarındaki tüketici ve onların deposundaki Sağlayıcı. Daha sonra, merkezi noktada, sözleşme ikisinin dışında yaşar.

Argümanlar

Kontrattan teste geçiş söz konusu olduğunda karşı çıkmakta zorlandığımız argümanlar şunlardır:

• Entegrasyon testleri oluşturmak için kullanılabilecek Swagger belgeleri zaten mevcut.
• Ekipler, API değişiklikleri için etkili bir mekanizma ile hem ön uç hem de arka uç hizmetlerine sahiptir.

Sürekli Entegrasyon

Bu, sürekli entegrasyon testi paketinize nasıl uyuyor? Sözleşme testinin hayata geçirilmesi için istenen yer, birim testlerinizdir.

Tüketici testleri, test dışında hiçbir harici bağımlılık gerektirmeyen sahte bir sunucuyu çalıştırır.

Sağlayıcı testleri bir API örneği gerektirir, bu nedenle yerel API bir bellek içi test sunucusu . Ancak, API'nizi yerel olarak paketlemek kolay değilse, daha önce kullandığımız bir geçici çözüm, bir ortamı oluşturduğumuz ve kodu, çekme isteği otomatik kontrollerinin bir parçası olarak bu ortama dağıttığımız yerdir.

(resim kaynak )

Sonuç

Bu eğiticide, sözleşme testinin ne anlama geldiğini ve bir mikro hizmet altyapısında neye benzediğini öğrendik ve gerçek dünya örneğinde nasıl göründüğünü gördük.

Sözleşme testinin entegrasyon testlerinizi sola kaydırmanıza nasıl yardımcı olabileceği hakkında dersler alındı. Ek olarak, entegrasyon sorunları ile ilgili geri bildirim sürelerini azaltarak kuruluşunuzun maliyetlerini nasıl azaltabileceğini gördük.

Sözleşme testi yalnızca teknik test için bir araç değildir, değişiklikleri ileterek ve testi tek bir birim olarak teşvik ederek geliştirme ekiplerinin işbirliğini güçlendirir. Genel olarak bu, Sürekli Dağıtıma geçmek isteyen herkes için bir ön koşul olmalıdır.

SONRAKİ Eğitici

Önerilen Kaynaklar

• JavaScript'te Tüketici Anlaşması Testi Nasıl Yazılır
• Pact CLI ile Pact Sözleşmesini ve Sürekli Dağıtımı Doğrulayın
• Pact Broker'a Pact Sözleşmesi Nasıl Yayınlanır
• Sürekli Entegrasyon Süreci: Yazılım Kalitesini İyileştirme ve Riski Azaltma
• Birim Testi, Entegrasyon Testi ve İşlevsel Test Arasındaki Farklar
• Entegrasyon Testi Nedir (Entegrasyon Testi Örneği ile Eğitim)
• Entegrasyon Testlerini Yazmak için En İyi 10 Entegrasyon Test Aracı
• DevOps'ta Sürekli Dağıtım