Davranış Odaklı Geliştirme - Hızlı Kılavuz

Davranış Odaklı Geliştirme (BDD), orijinal olarak Test Güdümlü Geliştirme'den (TDD) ortaya çıkan bir yazılım geliştirme sürecidir.

BDD'nin evriminden sorumlu Dan North'a göre, "BDD, önemli bir yazılım sunmak için ortak bir anlayış oluşturmak ve belirsizliği ortaya çıkarmak için birden çok düzeyde örnekler kullanıyor."

BDD, geliştirmeye dahil olan herkes için okunabilir ve anlaşılır bir dilde yazılmış sistemin davranışını göstermek için örnekler kullanır. Bu örnekler şunları içerir -

• Yürütülebilir spesifikasyonlara dönüştürüldü.

• Kabul testleri olarak kullanılır.

BDD - Anahtar özellikler

Davranış Odaklı Geliştirme şunlara odaklanır:

• İş değeri olan bir ürün sunmak amacıyla yazılım geliştirmede işbirliği yapmak için yazılım geliştiriciler, iş analistleri ve paydaşlarla iletişimi teşvik eden ortak bir süreç ve paylaşılan araçlar sağlamak.

• Bir sistemin nasıl uygulanması gerektiği değil, ne yapması gerektiği.

• Daha iyi okunabilirlik ve görünürlük sağlar.

• Yazılımın sadece çalıştığını değil, aynı zamanda müşterinin beklentilerini karşıladığını da doğrulamak.

BDD'nin Kökeni

Bir kusuru düzeltmenin maliyeti, kusur doğru zamanda tespit edilmezse ve tespit edildiğinde düzeltilmezse çok kat artar. Aşağıdaki örneği düşünün.

Bu, gereksinimler doğru bir şekilde sağlanmadıkça, daha sonraki bir aşamada gereksinimlerin yanlış anlaşılmasından kaynaklanan kusurları düzeltmenin pahalı olacağını gösterir. Ayrıca, son ürün müşterinin beklentilerini karşılamayabilir.

Saatin ihtiyacı bir geliştirme yaklaşımıdır -

• Gereksinimlere dayanmaktadır.

• Geliştirme boyunca gereksinimlere odaklanır.

• Gereksinimlerin karşılanmasını sağlar.

Yukarıda belirtilen gereksinimleri karşılayabilecek bir geliştirme yaklaşımı BDD'dir. Böylece, Davranış Odaklı Geliştirme -

• Sistemin farklı beklenen davranışlarının örneklerini türetir.

• Müşteriler de dahil olmak üzere geliştirmeye dahil olan herkesin kolayca anlayabilmesi için örneklerin iş alanı terimlerini kullanarak bir dilde yazılmasını sağlar.

• Zaman zaman müşteri ile onaylanan örnekleri görüşmeler yoluyla alır.

• Geliştirme boyunca müşteri gereksinimlerine (örnekler) odaklanır.

• Örnekleri kabul testleri olarak kullanır.

BDD Uygulamaları

BDD'nin iki ana uygulaması şunlardır:

• Örneğe Göre Tanımlama (SbE)

• Test Odaklı Geliştirme (TDD)

Örneğe Göre Şartname

Örneklerle Tanımlama (SbE), iş kurallarını ve oluşturulacak yazılımın davranışını göstermek için konuşmalardaki örnekleri kullanır.

Örneklerle Spesifikasyon, ürün sahiplerinin, iş analistlerinin, test uzmanlarının ve geliştiricilerin iş gereksinimleri hakkındaki yaygın yanlış anlamaları ortadan kaldırmasını sağlar.

Test Odaklı Geliştirme

Test Güdümlü Geliştirme, BDD bağlamında, örnekleri insan tarafından okunabilir, yürütülebilir spesifikasyonlara dönüştürür.

Geliştiriciler, bu özellikleri, yeni işlevsellik artışlarını uygulamak için bir kılavuz olarak kullanır. Bu, yazılımın kullanım ömrü boyunca bakım maliyetlerini düşük tutan yalın bir kod tabanı ve bir dizi otomatik regresyon testi ile sonuçlanır.

Çevik BDD

Çevik yazılım geliştirmede, BDD yöntemi, bekleyen özellikler üzerinde ortak bir anlayışa varmak için kullanılır.

Aşağıdaki adımlar Agile BDD'de yürütülür -

• Geliştiriciler ve ürün sahibi, bekleyen özellikleri birlikte düz bir metin düzenleyicide yazarlar.

• Ürün sahibi, sistemden beklediği davranışları belirtir.

• Geliştiriciler

  • Spesifikasyonları bu davranış ayrıntılarıyla doldurun.

  • Sistemi anlayışlarına göre sorular sorun.

• Mevcut sistem davranışları, yeni özelliğin mevcut özelliklerden herhangi birini bozup bozmayacağını görmek için kabul edilir.

Çevik Manifesto ve BDD

Çevik Manifesto şunları belirtir:

Bunu yaparak ve başkalarının yapmasına yardımcı olarak yazılım geliştirmenin daha iyi yollarını ortaya çıkarıyoruz. Bu çalışma sayesinde, değer kazandık -

• Individuals and interactions - Süreçler ve araçlar üzerinde

• Working software - Kapsamlı dokümantasyondan fazlası

• Customer collaboration - Sözleşme müzakeresi üzerinden

• Responding to change - Bir planı takip etmek

Yani sağdaki öğelerde değer varken soldaki öğelere daha çok değer veriyoruz.

BDD, Agile manifestosuna şu şekilde uyum sağlar:

Çevik Manifesto	BDD Hizalaması
Süreçler ve araçlardan ziyade bireyler ve etkileşimler.	BDD, sohbet etmekle ilgilidir.
Kapsamlı dokümantasyon yerine çalışan yazılım.	BDD, ticari değeri olan yazılımları oluşturmayı kolaylaştırmaya odaklanır.
Sözleşme pazarlığı yerine müşteri işbirliği.	BDD, gelişim ilerledikçe müşteriyle sürekli iletişim halinde olan fikirlere dayalı senaryolara odaklanır. Herhangi bir söze dayanmamaktadır.
Bir planı takip etmek yerine değişime yanıt vermek.	BDD, değişikliklerin özümsenmesini kolaylaştıran sürekli iletişim ve işbirliğine odaklanır.

Davranış Odaklı Geliştirme ile ilgili herhangi bir referansa baktığınızda, "BDD, TDD'den türetilmiştir", "BDD ve TDD" gibi ifadelerin kullanımını göreceksiniz. BDD'nin nasıl ortaya çıktığını, neden TDD'den türetildiğini ve BDD ve TDD'nin ne olduğunu bilmek için TDD'yi anlamanız gerekir.

Neden Test Etmelisiniz?

Başlamak için, test etmenin temellerine girelim. Testin amacı, inşa edilen sistemin beklendiği gibi çalıştığından emin olmaktır. Aşağıdaki örneği düşünün.

Bu nedenle, deneyimle, bir kusuru ortaya çıktığı anda ortaya çıkarmanın ve hemen düzeltmenin uygun maliyetli olacağını öğrendik. Bu nedenle, geliştirme ve testin her aşamasında test senaryoları yazma zorunluluğu vardır. Bu, geleneksel test uygulamalarımızın bize öğrettiği şeydir ve bu, genellikle Test-erken olarak adlandırılır.

Bu test yaklaşımı, test bir aşamanın tamamlanmasından sonra yapıldığı için Test-Son yaklaşımı olarak adlandırılır.

Son Test Yaklaşımıyla Karşılaşılan Zorluklar

Yazılım geliştirme projelerinde oldukça uzun bir süre Test-Last yaklaşımı izlendi. Bununla birlikte, gerçekte, bu yaklaşımla, testin belirli aşama tamamlanana kadar beklemesi gerektiğinden, genellikle şu sebeplerden dolayı gözden kaçar:

• Etabın tamamlanmasındaki gecikmeler.

• Sıkı zaman programları.

• Zamanında teslimata odaklanın, testi atlayın.

Ayrıca, Son Test yaklaşımında, geliştiriciler tarafından yapılması gereken Birim testi genellikle atlanır. Bulunan çeşitli nedenler, geliştiricilerin zihniyetine dayanmaktadır -

• Onlar geliştiricilerdir, testçiler değiller.

• Test, test uzmanlarının sorumluluğundadır.

• Kodlamada etkilidirler ve kodlarında kusur olmaz.

Bu sonuç -

• Teslim edilen ürünün kalitesinden ödün vermek.

• Yalnızca test uzmanları üzerinde kalite sorumluluğuna sahip olmak.

• Teslimat sonrası kusurların giderilmesinde yüksek maliyet.

• Müşteri memnuniyetinin sağlanamaması, bu aynı zamanda tekrarlanan işlerin kaybedilmesi anlamına gelir ve dolayısıyla güvenilirliği etkiler.

Bu faktörler, teste odaklanmak için paradigmada bir değişiklik gerektirdi. Sonuç Test-Önce yaklaşımı oldu.

İlk Test Yaklaşımı

Önce Test yaklaşımı, içten dışa (kodu yazın ve sonra test edin) geliştirmenin dıştan içe (testi yazın ve sonra kodlayın) yöntemiyle değiştirir.

Bu yaklaşım, aşağıdaki yazılım geliştirme metodolojilerine dahil edilmiştir (bunlar aynı zamanda Çeviktir) -

• eXTreme Programlama (XP).

• TAvustralya, Brezilya ve Kuzey Amerika ülkelerinin kullandığı saat uygulaması Dyarılmış Dgelişme (TDD).

Bu metodolojilerde, geliştirici, kod modülünün tek bir satırını yazmadan önce bir kod modülü için Birim testleri tasarlar ve yazar. Geliştirici daha sonra Birim testini geçmek amacıyla kod modülünü oluşturur. Bu nedenle, bu metodolojiler geliştirmeyi yönlendirmek için Birim testini kullanır.

Unutulmaması gereken temel nokta, hedefin teste dayalı geliştirme olmasıdır.

Kırmızı-Yeşil-Refaktör Döngüsü

Test Güdümlü Geliştirme, Birim testleri tarafından yönlendirilen kodu geliştirmek için kullanılır.

Step 1 - Yazılması gereken bir kod modülünü düşünün.

Step 2 - Bir test yazın

Step 3 - Testi çalıştırın.

Kod hala yazılmadığı için test başarısız olur. Bu nedenle, 2. Adım genellikle başarısız olmak için bir test yazma olarak adlandırılır.

Step 4 - Testi geçmek için mümkün olan minimum kodu yazın.

Step 5- Hepsinin hala başarılı olduğundan emin olmak için tüm testleri çalıştırın. Bu adımı kolaylaştırmak için birim testleri otomatikleştirilmiştir.

Step 6 - Yeniden düzenleme.

Step 7 - Sonraki kod modülü için Adım 1 ila Adım 6'yı tekrarlayın.

Her döngü çok kısa olmalı ve tipik bir saat birçok döngü içermelidir.

Bu aynı zamanda halk arasında Red-Green-Refactor döngü, nerede -

• Red - Başarısız olan bir test yazmak.

• Green - Testi geçmek için kod yazma.

• Refactor - Yinelemeyi kaldırın ve kodu kabul edilebilir standartlara iyileştirin.

TDD İşlem Adımları

Bir TDD işleminin aşamaları aşağıda gösterilmektedir.

TDD'nin Avantajları

Test Odaklı Geliştirmenin faydaları veya avantajları şunlardır:

• Geliştiricinin ilk olarak, istenen sonucun ne olması gerektiğini ve kodu oluşturmadan önce nasıl test edeceğini anlaması gerekir.

• Bir bileşenin kodu yalnızca test başarılı olduğunda ve kod yeniden düzenlendiğinde biter. Bu, geliştirici bir sonraki teste geçmeden önce test ve yeniden düzenleme yapılmasını sağlar.

• Birim testleri paketi her yeniden düzenlemeden sonra çalıştırıldığından, her bileşenin hala çalıştığına dair geri bildirim sabittir.

• Birim testleri, her zaman verilere bağlı olan canlı belgeler görevi görür.

• Bir kusur bulunursa, geliştirici bu hatayı ortaya çıkarmak için bir test oluşturur ve ardından testi geçecek ve kusur düzeltilecek şekilde kodu değiştirir. Bu, hata ayıklama süresini azaltır. Diğer tüm testler de çalıştırılır ve geçtiklerinde mevcut işlevselliğin bozulmamasını sağlar.

• Geliştirici istediği zaman tasarım kararları verebilir ve yeniden düzenleyebilir ve testlerin çalıştırılması sistemin hala çalıştığından emin olur. Bu, yazılımı bakım yapılabilir hale getirir.

• Geliştirici herhangi bir değişiklik yapma güvenine sahiptir, çünkü değişiklik mevcut herhangi bir işlevi etkiliyorsa, aynısı testler çalıştırılarak ortaya çıkar ve kusurlar hemen giderilebilir.

• Birbirini izleyen her test çalıştırmasında, önceki tüm hata düzeltmeleri de doğrulanır ve aynı hatanın tekrarlanması azaltılır.

• Testlerin çoğu geliştirme sırasında yapıldığından, teslimattan önceki testler kısaltılır.

TDD'nin dezavantajları

Başlangıç ​​noktası, sistemin davranışını açıklayan Kullanıcı Hikayeleridir. Bu nedenle, geliştiriciler genellikle aşağıdaki sorularla karşılaşırlar:

• Ne zaman test edilmeli?

• Ne test edilmeli?

• Bir şartnamenin karşılanıp karşılanmadığını nasıl anlarım?

• Kod iş değeri sağlıyor mu?

TDD ile ilgili yanılgılar

Aşağıdaki yanlış anlamalar sektörde mevcuttur ve açıklamaya ihtiyaç duyar.

Yanlış kanı	Açıklama
TDD tamamen test ve test otomasyonu ile ilgilidir.	TDD, Test-First yaklaşımını kullanan bir geliştirme metodolojisidir.
TDD herhangi bir tasarım içermez.	TDD, gereksinimlere göre kritik analiz ve tasarımı içerir. Tasarım, geliştirme sırasında ortaya çıkar.
TDD yalnızca Birim seviyesindedir.	TDD, entegrasyon ve sistem seviyelerinde kullanılabilir.
TDD, geleneksel test projeleri tarafından kullanılamaz.	TDD, Extreme Programming ile popüler hale geldi ve diğer Agile metodolojilerinde kullanılıyor. Ancak geleneksel test projelerinde de kullanılabilir.
TDD bir araçtır.	TDD bir geliştirme metodolojisidir ve her yeni Birim Testi geçtikten sonra, tüm testlerin yeni bir kod eklendiğinde veya mevcut kod değiştirildiğinde ve ayrıca her yeniden düzenleme işleminden sonra çalıştırılması gerektiğinden Otomasyon Test Paketine eklenir. Böylece TDD'yi destekleyen Test Otomasyon Araçları bu süreci kolaylaştırır.
TDD, Kabul testlerini geliştiricilere teslim etmek anlamına gelir.	TDD, Kabul Testlerini geliştiricilere vermek anlamına gelmez.

Kabul TDD

Kabul Testi Güdümlü Geliştirme (ATDD), geliştirmenin başlarında Kullanıcı Hikayelerinin oluşturulması sırasında Kabul Kriterlerini ve Kabul Testlerini tanımlar. ATDD, müşteriler, geliştiriciler ve test ediciler arasındaki iletişime ve ortak anlayışa odaklanır.

ATDD'deki temel uygulamalar aşağıdaki gibidir -

• Etki alanı hakkında ortak bir anlayış oluşturmak için gerçek dünya senaryolarını tartışın.

• Kabul kriterlerine ulaşmak için bu senaryoları kullanın.

• Kabul testlerini otomatikleştirin.

• Geliştirmeyi bu testlere odaklayın.

• Değişikliği kolaylaştırmak için testleri canlı bir spesifikasyon olarak kullanın.

ATDD kullanmanın faydaları aşağıdaki gibidir -

• Gereksinimler nettir ve işlevsel boşluklar yoktur.

• Diğerleri, geliştiricilerin öngördüğü özel durumları anlar.

• Kabul testleri geliştirmeye rehberlik eder.

TDD Vs BDD

Dan North'a göre, programcılar Test Güdümlü Geliştirme gerçekleştirirken normalde aşağıdaki sorunlarla karşılaşır:

• Nereden başlamalı

• Neyi test etmeli ve neyi test etmemeli

• Tek seferde ne kadar test edilecek

• Testlerine ne denir

• Bir testin neden başarısız olduğu nasıl anlaşılır?

Tüm bu sorunların çözümü Davranış Odaklı Geliştirmedir. Yerleşik çevik uygulamalardan gelişmiştir ve bunları ekipler için daha erişilebilir ve etkili hale getirmek, çevik yazılım tesliminde yeni hale getirmek için tasarlanmıştır. BDD, zamanla çevik analiz ve otomatik kabul testinin daha geniş resmini kapsayacak şekilde büyümüştür.

Ana difference between TDD and BDD bu -

• TDD, yazılımın nasıl çalıştığını açıklar.

• Öte yandan BDD -

  • Son kullanıcının yazılımı nasıl kullandığını açıklar.

  • İşbirliğini ve iletişimi teşvik eder.

  • Sistemin davranış örneklerini vurgular.

  • Örneklerden türetilen çalıştırılabilir özelliklerde amaçlar

TDD'de "Kabul Testleri" yanıltıcıdır. Kabul testleri aslında sistemin beklenen davranışını temsil eder. Çevik uygulamalarda, tüm ekibin iş birliği ve müşteri ve diğer paydaşlarla etkileşime vurgu yapılır. Bu, projeye dahil olan herkes tarafından kolayca anlaşılan terimlerin kullanılması gerekliliğini doğurmuştur.

TDD, gerekli olanları düşünmenizi sağlar Behavior ve bu nedenle 'Davranış' terimi, ‘Test’. BDD, testlere değil davranışa odaklanan bir kelime dağarcığı içeren Test Odaklı Geliştirmedir.

Dan North'un sözleriyle, "Testlerde düşünmekten davranışta düşünmeye geçişi o kadar derin buldum ki, TDD'den BDD veya Davranış Odaklı Geliştirme olarak bahsetmeye başladım." TDD bir şeyin nasıl çalışacağına odaklanır, BDD onu neden inşa ettiğimize odaklanır.

BDD, geliştiricilerin sıklıkla karşılaştığı aşağıdaki soruları yanıtlıyor:

Soru	Cevap
Nereden başlamalı?	dıştan içe
Ne test edilmeli?	Kullanıcı hikayeleri
Neyi test etmemek?	başka herhangi bir şey

Bu cevaplar, aşağıdaki gibi hikaye çerçevesinde sonuçlanır -

Story Framework

Olarak [Role]

İstiyorum [Feature]

Böylece [Benefit]

Bu, ' Feature yürütülür, sonuç Benefit oynayan kişiye Role.'

BDD aşağıdaki soruları da yanıtlıyor -

Soru	Cevap
Tek seferde test etmek ne kadar?	çok az odaklanmış
Testlerine ne denir?	cümle şablonu
Bir testin neden başarısız olduğu nasıl anlaşılır?	dokümantasyon

Bu cevaplar aşağıdaki gibi Örnek çerçevede sonuçlanır -

Example Framework

Given başlangıç ​​bağlamı,

When bir olay meydana gelir,

Then bazı sonuçların sağlanması.

Bu, 'İlk bağlamdan başlayarak, belirli bir olay meydana geldiğinde, sonuçların ne olduğunu biliyoruz. should be. '

Bu nedenle, örnek sistemin beklenen davranışını göstermektedir. Örnekler, sistemin farklı senaryolarını göstermek için kullanılır.

Hikaye ve Senaryolar

Bir ATM sistemi ile ilgili olarak Dan North tarafından yapılan aşağıdaki resme bakalım.

Hikaye

As a müşteri,

I want ATM'den nakit çekmek için,

so that Bankada sıra beklememe gerek yok.

Senaryolar

Bu hikaye için iki olası senaryo var.

Scenario 1 - Hesap kredili

Given hesabın kredisi var

And kart geçerlidir

And dağıtıcı nakit içeriyor

When müşteri nakit istiyor

Then hesabın borçlandırıldığından emin olun

And Nakit dağıtıldığından emin olmak

And kartın iade edildiğinden emin olun

Scenario 2 - Hesap limit aşımına uğradı

Given hesap fazla çekilmiş

And kart geçerlidir

When müşteri nakit istiyor

Then bir ret mesajının görüntülenmesini sağlayın

And Nakit dağıtılmamasını sağlamak

And kartın iade edildiğinden emin olun

Olay her iki senaryoda da aynıdır, ancak bağlam farklıdır. Dolayısıyla sonuçlar farklıdır.

Geliştirme Döngüsü

BDD için Geliştirme Döngüsü bir outside-in yaklaşmak.

Step 1- Kırmızıya dönüşen üst düzey (dış) bir iş değeri örneği (Salatalık veya RSpec / Kapibara kullanarak) yazın. (RSpec, Ruby dilinde bir BDD çerçevesi oluşturur)

Step 2 - Kırmızı olan uygulamanın ilk adımı için daha düşük seviyeli (içeriden) bir RSpec örneği yazın.

Step 3 - Bu alt düzey örneği geçmek için minimum kodu uygulayın, yeşile döndüğünü görün.

Step 4 - Kırmızı olan Adım 1'i geçmeye doğru ilerleyen bir sonraki düşük seviye RSpec örneğini yazın.

Step 5 - Adım 1'deki üst düzey örnek yeşil olana kadar Adım 3 ve Adım 4'ü tekrarlayın.

Note - Aşağıdaki noktalar akılda tutulmalıdır -

• Red/green devlet bir izin durumudur.

• Düşük seviyeli testleriniz yeşil olduğunda, yeni örnekler yazma veya mevcut uygulamayı yeniden düzenleme iznine sahip olursunuz. Yeniden düzenleme bağlamında yeni işlevsellik / esneklik eklememelisiniz.

• Düşük seviyeli testleriniz kırmızı olduğunda, yalnızca mevcut testlerin yeşile dönmesi için uygulama kodunu yazma veya değiştirme iznine sahip olursunuz. Var olmayan bir sonraki testinizi geçmek için kodu yazma dürtüsüne direnmelisiniz veya iyi olduğunu düşündüğünüz özellikleri (müşteri istemezdi) uygulamaya koymalısınız.

'Örneklerle Spesifikasyon' kitabının yazarı Gojko Adzic'e göre, Örneklerle Spesifikasyon, doğru ürünün verimli bir şekilde teslim edilmesini sağlamak için yazılım ürünlerindeki değişimi kolaylaştıran bir dizi süreç modelidir. "

Örneklerle Spesifikasyon, soyut ifadeler yerine gerçekçi örnekler kullanarak gereksinimleri yakalamaya ve göstermeye dayanan yazılım ürünleri için gereksinimleri ve iş odaklı fonksiyonel testleri tanımlamak için işbirliğine dayalı bir yaklaşımdır.

Örneklerle Spesifikasyon - Genel Bakış

Örneklerle Spesifikasyonun amacı, önceliklendirilmiş, doğrulanabilir iş gereksinimlerinin geliştirilmesine ve sağlanmasına odaklanmaktır. Örneklerle Spesifikasyon kavramı kendi içinde nispeten yeni olsa da, sadece mevcut uygulamaların yeniden ifade edilmesidir.

Her yerde bulunan dil olarak bilinen çok spesifik, özlü bir kelime dağarcığını destekler.

• Yürütülebilir gereksinimleri etkinleştirir.

• Takımdaki herkes tarafından kullanılır.

• Çapraz işlevli bir ekip tarafından oluşturulur.

• Herkesin anlayışını yakalar.

Örneklerle Spesifikasyon, iş alanını yansıtan Otomatikleştirilmiş testlerin oluşturulmasında doğrudan bir girdi olarak kullanılabilir. Bu nedenle, Örneklerle Spesifikasyonun odak noktası, doğru ürünü oluşturmak ve ürünü doğru oluşturmaktır.

Örneğe Göre Spesifikasyonun Amacı

Örneklerle Spesifikasyonun birincil amacı doğru ürünü oluşturmaktır. Ortak anlayışa odaklanır, böylece tek bir hakikat kaynağı oluşturur. Kusur tespiti yerine kusur önleme üzerine odaklanılması için kabul kriterlerinin otomasyonunu sağlar. Ayrıca, kusurları erken bulmak için testi erken teşvik eder.

SbE kullanımı

Örneklerle Tanımlama, iş değerini tanımlayan beklenen sistem davranışını göstermek için kullanılır. Örnek somut ve gerçek hayattan örneklerle verilmiştir. Bu örnekler, aşağıdaki çalıştırılabilir gereksinimleri oluşturmak için kullanılır:

• Çeviri olmadan test edilebilir.

• Canlı belgelerde yakalandı.

Aşağıda, belirli özellikleri açıklamak için örnekler kullanmamızın nedenleri verilmiştir -

• Anlaması daha kolay.

• Yanlış yorumlamaları daha zordur.

SbE'nin Avantajları

Spesifikasyonu Örneklerle kullanmanın avantajları şunlardır:

• Artan kalite

• Daha az atık

• Azaltılmış üretim hatası riski

• Odaklı çaba

• Değişiklikler daha güvenli yapılabilir

• Gelişmiş iş katılımı

SbE Uygulamaları

Örneklere Göre Şartname uygulamaları bul -

• Karmaşık iş veya karmaşık organizasyon.

• Tamamen teknik sorunlar için iyi çalışmıyor.

• UI odaklı yazılım ürünlerinde iyi çalışmaz.

• Eski sistemlere de uygulanabilir.

SbE ve Kabul Testi

Kabul testi açısından Örnekle Spesifikasyonun avantajları şunlardır:

• Hem ayrıntılı gereksinimler hem de testler için tek bir örnek kullanılmıştır

• Projenin ilerlemesi Kabul testleri açısından -

  • Her test bir davranışı test etmektir.

  • Bir test ya bir davranış için geçer ya da geçmez.

  • Başarılı bir test, belirli davranışın tamamlandığını gösterir.

  • Tamamlanması için 100 davranış gerektiren bir proje, tamamlanmış 60 davranışa sahipse,% 60'ı tamamlanmış demektir.

• Test uzmanları, hata tespitinden hata önlemeye geçer ve çözümün tasarımına katkıda bulunur.

• Otomasyon, bir gereksinim değişikliğinin çözüm üzerindeki etkisinin anında anlaşılmasını sağlar.

Örneklerle Tanımlama - Farklı Roller için ne anlama geliyor?

Örneklerle Spesifikasyonun amacı, iş değeri sağlamak için proje boyunca müşteri de dahil olmak üzere ekipteki herkesin işbirliğini teşvik etmektir. Daha iyi anlaşılması için herkes aynı Kelime Dağarcığını kullanır.

Rol	SbE kullanımı
İş analisti	Gereksinimler nettir ve işlevsel boşluklar yoktur. Geliştiriciler, aslında spesifikasyonları okuyun.
Geliştirici	Geliştiriciler neyin geliştirildiğini daha iyi anlar. Doğru geliştirilmiş spesifikasyonlar sayılarak geliştirme ilerlemesi daha iyi izlenir.
Test cihazı	Testçiler neyin test edildiğini daha iyi anlar. Test uzmanları başlangıçtan itibaren dahil olurlar ve tasarımda rol alırlar. Test uzmanları, kusur tespiti yerine kusur önlemeye yönelik çalışır.
Herkes	Hataları baştan tanımlayarak zamandan tasarruf edilir. Başlangıçtan itibaren kaliteli bir ürün üretilir.

SbE - Bir Süreç Modeli Seti

Bu bölümün başında gördüğümüz gibi, Örneklerle Spesifikasyon, doğru ürünün verimli bir şekilde teslim edilmesini sağlamak için yazılım ürünlerindeki değişimi kolaylaştıran bir dizi işlem modeli olarak tanımlanır.

Süreç kalıpları -

• İşbirlikçi şartname

• Spesifikasyonları örnekler kullanarak açıklama

• Spesifikasyonu iyileştirmek

• Otomatikleştirme örnekleri

• Sıklıkla doğrulama

• Yaşayan belgeler

Ortak Çalışma Şartnamesi

İşbirliğine dayalı şartnamenin amaçları şunlardır:

• Ortak bir anlayışa ve ortak bir kelime dağarcığına sahip olmak için bir takımdaki çeşitli rolleri alın.

• Bir özellikle ilgili farklı bakış açılarına katkıda bulunabilmeleri için herkesi projeye dahil edin.

• Özelliklerin ortak iletişimini ve sahipliğini sağlayın.

Bu hedeflere, Üç Kafadar toplantısı olarak da bilinen bir spesifikasyon atölyesinde ulaşılır. Üç Kafadar, BA, QA ve geliştiricidir. Projede başka roller olsa da, bu üçü özelliklerin tanımından teslimine kadar sorumlu ve sorumlu olacaktır.

During the meeting −

• İş Analisti (BA), yeni bir özellik için gereksinimleri ve testleri sunar.

• Üç Amigo (BA, Geliştirici ve QA) yeni özelliği tartışıyor ve spesifikasyonları gözden geçiriyor.

• QA ve geliştirici ayrıca eksik gereksinimleri de belirler.

• Üç Kafadarlar

  • Her yerde bulunan bir dil kullanarak paylaşılan bir model kullanın.

  • Etki alanı sözlüğünü kullanın (Gerekirse bir sözlük tutulur).

  • Farklılıkları ve çatışmaları arayın.

• Bu noktada uygulama ayrıntılarına atlamayın.

• Bir özelliğin yeterince belirtilip belirtilmediği konusunda fikir birliğine varın.

• Ortak bir gereksinim duygusu ve test sahipliği, kalite spesifikasyonlarını kolaylaştırır

• Gereksinimler, açık, kesin gereksinimler sağlayan senaryolar olarak sunulur. Bir senaryo, kullanıcıların bakış açısından sistemin davranışına bir örnektir.

Örnekler Kullanarak Spesifikasyonu Gösterme

Senaryolar, test edilebilir bir belirtim oluşturmak için Given-When-Then yapısı kullanılarak belirlenir -

Given <bazı ön koşullar>

And <ek ön koşullar> Optional

When <bir eylem / tetikleyici oluşur>

Then <bazı yayın koşulları>

And <ek gönderi koşulları> Optional

Bu belirtim, sistemin davranışına bir örnektir. Aynı zamanda sistemin bir Kabul kriterini temsil eder.

Ekip örnekleri tartışır ve geri bildirim, örneklerin özelliğin beklenen davranışını kapsadığı konusunda mutabakat sağlanana kadar dahil edilir. Bu, iyi bir test kapsamı sağlar.

Spesifikasyonu İyileştirme

Bir spesifikasyonu iyileştirmek için,

• Örnekleri yazarken kesin olun. Bir örnek karmaşık hale gelirse, onu daha basit örneklere bölün.

• İş perspektifine odaklanın ve teknik ayrıntılardan kaçının.

• Hem olumlu hem de olumsuz koşulları düşünün.

• Alana özgü kelime dağarcığına bağlı kalın.

• Örnekleri müşteriyle tartışın.

  • Bunu başarmak için konuşmaları seçin.

  • Yalnızca müşterinin ilgilendiği örnekleri düşünün. Bu, yalnızca gerekli kodun üretilmesini sağlar ve gerekli olmayabilecek olası her kombinasyonu kapsamayı önler

• Senaryonun başarılı olmasını sağlamak için, o senaryo için tüm test durumlarının geçmesi gerekir. Bu nedenle, test edilebilir hale getirmek için spesifikasyonları geliştirin. Test senaryoları, çeşitli aralıkları ve veri değerlerini (sınır ve köşe durumları) ve verilerde değişikliklere neden olan farklı iş kurallarını içerebilir.

• Karmaşık hesaplamalar, veri işleme / dönüştürme vb. Gibi ek iş kurallarını belirtin.

• İşlevsel olmayan senaryoları (ör. Performans, yük, kullanılabilirlik, vb.) Örneklerle Spesifikasyon olarak dahil edin

Otomatikleştirme Örnekleri

Otomasyon katmanının çok basit tutulması gerekir - sadece spesifikasyonun test edilen sisteme bağlanması. Aynısı için bir araç kullanabilirsiniz.

Etki Alanına Özgü Dil (DSL) kullanarak test otomasyonu gerçekleştirin ve girişler ile çıkışlar arasında net bir bağlantı gösterin. Komut dosyasına değil, spesifikasyona odaklanın. Testlerin kesin, anlaşılması kolay ve test edilebilir olduğundan emin olun.

Sıklıkla Doğrulama

Her değişiklikle (ekleme / değiştirme) geliştirme hattınıza örnek doğrulama ekleyin. Bir ürünün kalitesinin sağlanmasına yardımcı olmak için benimsenebilecek (ve uygulanması gereken) birçok teknik ve araç vardır. Üç temel ilke etrafında dönüyorlar:Test Early, Test Well ve Test Often.

Zayıf bağlantıları tanımlayabilmek için testleri sık sık gerçekleştirin. Davranışları temsil eden örnekler ilerlemeyi izlemeye yardımcı olur ve bir davranışın ancak ilgili test geçtikten sonra tamamlandığı söylenir.

Yaşayan Belgeler

Teknik özellikleri olabildiğince basit ve kısa tutun. Spesifikasyonları düzenleyin ve iş ilerledikçe bunları geliştirin. Ekipteki herkes için belgeleri erişilebilir hale getirin.

Örnek İşlem Adımlarına Göre Spesifikasyon

Resim, Örneklere Göre Spesifikasyon'daki işlem adımlarını gösterir.

Anti-desenler

Anti-kalıplar, yazılım geliştirmede kötü bir programlama uygulaması olarak kabul edilen belirli kalıplardır. Yaygın sorunlara ortak yaklaşımlar olan, resmileştirilmiş ve genellikle iyi bir kalkınma uygulaması olarak kabul edilen tasarım modellerinin aksine, anti-modeller tam tersidir ve istenmez.

Anti-kalıplar çeşitli sorunlara yol açar.

Anti-desen	Problemler
İşbirliği yok	Birçok varsayım Yanlış bir şey inşa etmek Yanlış şeyi test etmek Kod bittiğinde habersiz
Kod bittiğinde habersiz	Testleri sürdürmek zor Spesifikasyonu anlamak zor İşletme temsilcilerinden ilgi kaybı
Çok ayrıntılı veya çok kullanıcı arayüzü merkezli örnekler	Testleri sürdürmek zor Özellikleri anlamak zor İşletme temsilcilerinden ilgi kaybı
Küçük bir çaba gerekli	Takımlar başarısız olduklarını ve erken hayal kırıklığına uğradıklarını düşünüyor

Sorunların Çözümü - Kalite

Anti-kalıpları takip ederek kalite sağlanabilir. Anti-kalıpların yarattığı sorunları en aza indirmek için yapmanız gerekenler -

• Örnekler kullanarak belirtmek için bir araya gelin.

• Örnekleri temizleyin ve iyileştirin.

• Örnekleri karşılayan bir kod yazın

• Örnekleri otomatikleştirin ve dağıtın.

• Her kullanıcı hikayesi için yaklaşımı tekrarlayın.

Anti-kalıplardan kaynaklanan sorunları çözmek, bağlılık anlamına gelir -

• Collaboration.

• Neye odaklanmak.

• İşe Odaklanmak.

• Hazır ol.

Yukarıdakilerin her birinin ne anlama geldiğini anlayalım.

İşbirliği

İşbirliği içinde -

• İş adamları, geliştiriciler ve test uzmanları kendi bakış açılarından girdi verir.

• Otomatik örnekler, ekibin doğru şeyi yaptığını kanıtlıyor.

• Süreç, testlerin kendisinden daha değerlidir.

Neye odaklanmak

Soruya odaklanmalısınız - 'ne'. 'Neye' odaklanırken -

• Olası tüm durumları kapsamaya çalışmayın.

• Farklı tür testler kullanmayı unutmayın.

• Örnekleri olabildiğince basit tutun.

• Örnekler, sistem kullanıcıları tarafından kolayca anlaşılabilir olmalıdır.

• Aletler, atölye çalışmalarında önemli bir rol oynamamalıdır.

İşe Odaklanmak

İşe odaklanmak için -

• Teknik özellikleri iş amacında tutun.

• Spesifikasyonları oluşturmaya ve incelemeye işi dahil edin.

• Otomasyon katmanındaki tüm ayrıntıları gizleyin.

Hazır ol

Aşağıdakilere hazırlıklı olun -

• Ekip uygulamaları değiştirilse bile faydalar hemen görünmez.

• SbE'yi tanıtmak zordur.

• Zaman ve yatırım gerektirir.

• Otomatik test ücretsiz gelmiyor.

Araçlar

Aletlerin kullanımı Örneklerle Tanımlama için zorunlu değildir, ancak uygulamada birkaç araç mevcuttur. Bir araç kullanılmasa bile Örnekle Tanımlamanın ardından başarılı olan durumlar vardır.

Aşağıdaki araçlar Örneklerle Teknik Özelliklerini destekler -

• Cucumber

• SpecFlow

• Fitnesse

• Jbehave

• Concordion

• Behat

• Jasmine

• Relish

• Speclog

Geliştirme ekipleri genellikle BDD'nin bir araç çerçevesi olduğu konusunda yanlış bir anlayışa sahiptir. Gerçekte BDD, bir araç çerçevesinden ziyade bir geliştirme yaklaşımıdır. Bununla birlikte, diğer geliştirme yaklaşımlarında olduğu gibi, BDD için de araçlar vardır.

Farklı platformlar ve programlama dilleri için çeşitli BDD Araçları kullanılmaktadır. Onlar -

• Salatalık (Yakut çerçevesi)

• SpecFlow (.NET çerçevesi)

• Davranış (Python çerçevesi)

• JBehave (Java çerçevesi)

• JBehave Web (Selenium entegrasyonlu Java çerçevesi)

• Marul (Python çerçevesi)

• Concordion (Java çerçevesi)

• Behat (PHP çerçevesi)

• Kahlan (PHP çerçevesi)

• DaSpec (JavaScript çerçevesi)

• Jasmine (JavaScript çerçevesi)

• Cucumber-js (JavaScript çerçevesi)

• Squish GUI Test Cihazı (JavaScript, Python, Perl, Ruby ve Tcl için BDD GUI Test Aracı)

• Spock (Groovy çerçevesi)

• Yadda (Jasmine gibi çerçeveler için Gherkin dil desteği (JavaScript çerçevesi))

Salatalık

Hıyar, dünya çapında kullanılan çalıştırılabilir özellikler için ücretsiz bir araçtır. Cucumber, yazılım geliştirme ekiplerinin, yazılımın düz metin olarak nasıl davranması gerektiğini açıklamasına olanak tanır. Metin, iş tarafından okunabilir, alana özgü bir dilde yazılır ve dokümantasyon, otomatik testler ve geliştirme yardımı olarak hizmet eder ve hepsi tek bir formatta toplanır. Cucumber ile kırktan fazla farklı konuşma dili (İngilizce, Çince vb.) Kullanabilirsiniz.

Salatalık - Temel Özellikler

Salatalığın temel özellikleri aşağıdaki gibidir -

• Salatalık, Yürütülebilir Spesifikasyonlar, Test Otomasyonu ve Yaşayan Dokümantasyon için kullanılabilir.

• Cucumber, herhangi bir dilde yazılmış Ruby, Java, NET, Flex veya web uygulamaları ile çalışır.

• Hıyar, FIT'in yaptığına benzer şekilde Tablolarda daha kısa Testleri destekler.

• Cucumber, gereksinimleri, otomatikleştirilmiş testleri ve dokümantasyonu uyumlu bir şekilde birleştirerek Yazılım Geliştirme Yaşam Döngüsünde devrim yarattı: yazılımı doğrulayan düz metin çalıştırılabilir özellikler.

SpecFlow

SpecFlow, .NET Platformu için bir BDD Aracıdır. SpecFlow, açık kaynaklı bir projedir. Kaynak kodu GitHub'da barındırılmaktadır.

SpecFlow, Özellikler için Gherkin Sözdizimini kullanır. Kornişon formatı, Salatalık tarafından tanıtıldı ve diğer araçlar tarafından da kullanılıyor. Kornişon dili, GitHub'da bir proje olarak korunur -https://github.com/cucumber/gherkin

Davranmak

Behave, Python çerçevesi için kullanılır.

• Behave, "özellikler" adlı bir dizinde depolanan üç tür dosyayla çalışır -

  • davranış senaryolarınızı içeren özellik dosyaları.

  • Senaryolar için Python adım uygulamalarını içeren "steps" dizini.

  • İsteğe bağlı olarak, bazı çevresel kontroller (adımlar, senaryolar, özellikler veya tüm şut maçından önce ve sonra çalıştırılacak kod).

• Davranış özellikleri Gherkin (bazı değişikliklerle) kullanılarak yazılır ve "ad.özellik" olarak adlandırılır.

• Bir özelliğe ve senaryoya eklenen etiketler, kendilerine iletilen "özellik" veya "senaryo" nesnesi aracılığıyla ortam işlevlerinde bulunur. Bu nesnelerde, özellikler dosyasında bulunma sırasına göre eklenen etiket adlarının bir listesi olan "etiketler" adı verilen bir nitelik vardır.

• Gherkin Standardında Değişiklikler -

  • Behave, standart Gherkin dosyalarını ayrıştırabilir ve Gherkin'i küçük harfli adım anahtar kelimelerine izin verecek şekilde genişletir çünkü bunlar bazen daha okunabilir özellik özelliklerine izin verebilir.

Marul

Marul, Salatalığa dayalı çok basit bir BDD aracıdır. Python projeleri için otomatik testler olarak düz metin işlevsel açıklamaları yürütebilir. Marul, BDD'deki en yaygın görevleri hedefler.

Konkordiyon

Concordion, Java Framework için Spesifikasyon Örneğini otomatikleştirmek için açık kaynaklı bir araçtır.

Temel özellikler basit olsa da, Güçlü uzantı çerçevesi API'si , özellik olarak Excel elektronik tablolarını kullanma, çıktıya ekran görüntüleri ekleme, günlük bilgilerini görüntüleme vb. Gibi işlevler eklemenize olanak tanır.

Concordion, paragrafları, tabloları ve uygun noktalama işaretlerini kullanarak spesifikasyonları normal dilde yazmanıza izin verir ve yapılandırılmış Dili Verilen / Ne Zaman / Sonra'yı kullanmak gerekli değildir.

Concordion, dahil olmak üzere diğer dillere taşındı -

• C # (Concordion.NET)

• Python (PyConcordion)

• Ruby (Ruby-Concordion)

Hıyar, Yürütülebilir teknik özellikleri, Test otomasyonunu ve Yaşam belgelerini destekleyen bir araçtır.

Davranış Odaklı Geliştirme, Örneklerle Spesifikasyonu genişletir. Ayrıca Test Odaklı Geliştirme en iyi uygulamalarını, özellikle dışarıdan içeriden çalışma perspektifini resmileştirir. Geliştirme çalışması, yürütülebilir spesifikasyonlara dayanmaktadır.

key features çalıştırılabilir özelliklerin oranı aşağıdaki gibidir -

• Yürütülebilir Özellikler şunlardır -

  • Sistemin davranışlarını temsil eden örneklerden türetilmiştir.

  • İşletme ve paydaşlar da dahil olmak üzere geliştirmeye dahil olan herkesin işbirliği ile yazılmıştır.

  • Kabul kriterine göre.

• Yürütülebilir özelliklere dayalı kabul testleri otomatikleştirilmiştir.

• Yürütülebilir spesifikasyonları ve otomatik testleri yazmak için paylaşılan, her yerde bulunan bir dil kullanılır.

  • Alana özgü terminoloji geliştirme boyunca kullanılır.

  • Müşteriler ve paydaşlar dahil herkes sistem, gereksinimleri ve uygulanması hakkında aynı şekilde konuşur.

  • Aynı terimler, gereksinimlerde, tasarım belgelerinde, kodda, testlerde vb. Mevcut sistemi tartışmak için kullanılır.

  • Herkes bir gereksinimi ve daha fazla gereksinimin nasıl oluşturulacağını okuyup anlayabilir.

  • Değişiklikler kolaylıkla yerine getirilebilir.

  • Canlı dokümantasyon tutulur.

Hıyar, çalıştırılabilir özellikleri sistemin gerçek kodu ve otomatik kabul testleri ile bir araya getirdiği için bu sürece yardımcı olur.

Bunu yapma şekli aslında müşterilerin ve geliştiricilerin birlikte çalışmasını sağlamak için tasarlanmıştır. Bir kabul testi geçtiğinde, temsil ettiği sistemin davranışının spesifikasyonunun doğru bir şekilde uygulandığı anlamına gelir.

Tipik Salatalık Kabul Testi

Aşağıdaki örneği düşünün.

Feature − Sign up

• Kayıt hızlı ve kolay olmalıdır.

• Senaryo - Başarılı kayıt

  • New kullanıcılar bir onay e-postası almalı ve kişisel olarak karşılanmalıdır.

  • Given Kaydolmayı seçtim.

  • When Geçerli detaylarla kayıt oluyorum.

  • Then Bir onay e-postası almalıyım.

  • And Kişiselleştirilmiş bir karşılama mesajı görmeliyim.

Bu örnekten şunu görebiliriz -

• Kabul testleri, Features.

• Özellikler şu şekilde açıklanmaktadır: Scenarios.

• Senaryolar şunlardan oluşur: Steps.

Spesifikasyon, düz bir metin dosyasında doğal bir dilde yazılır, ancak çalıştırılabilir.

Salatalığın İşlenmesi

Cucumber, sisteminize karşı yürütülebilecek senaryoları arayan özellikleri içeren metin dosyalarını işleyen bir komut satırı aracıdır. Salatalığın nasıl çalıştığını anlayalım.

• Başlamayı kolaylaştırmak için dosyaların nasıl adlandırıldığı ve nerede bulundukları (ilgili klasörler) hakkında bir dizi kuraldan yararlanır.

• Salatalık, teknik özellikleri, otomatik testleri ve belgeleri aynı yerde tutmanızı sağlar.

• Her senaryo, senaryonun ön koşullarını, eylemlerini ve son koşullarını tanımlayan adımların bir listesidir; her adım herhangi bir hata olmadan yürütülürse, senaryo başarılı olarak işaretlenir.

• Bir çalışmanın sonunda, Cucumber kaç senaryonun geçtiğini bildirecektir.

• Bir şey başarısız olursa, geliştiricinin ilerleyebilmesi için neyin başarısız olduğu hakkında bilgi sağlar.

Salatalıkta, Features, Scenariosve Adımlar adlı bir Dilde yazılmıştır Gherkin.

Kornişon bir yapıya sahip düz metin İngilizcedir (veya 60'tan fazla diğer dilden biridir). Kornişon öğrenmesi kolaydır ve yapısı, kısa ve öz bir şekilde örnekler yazmanıza olanak tanır.

• Salatalık, Gherkin'de yazılmış çalıştırılabilir özellikler içeren dosyalarınızı yürütür.

• Hıyar, düz metinli Kornişon Adımlarını sistemle etkileşime girecek eylemlere dönüştürmek için Adım Tanımlarına ihtiyaç duyar.

• Cucumber bir senaryodaki bir adımı yürüttüğünde, yürütmek için eşleşen bir adım tanımı arayacaktır.

• Adım Tanımı, kendisine eklenmiş bir model bulunan küçük bir kod parçasıdır.

• Kalıp, Adım Tanımını tüm eşleşen adımlara bağlamak için kullanılır ve kod, Salatalığın bir Kornişon adımını gördüğünde yürüteceği şeydir.

• Her adıma bir Adım Tanımı eşlik eder.

• Çoğu adım girdi toplar ve ardından çerçevenizde çağrılar yapmak için uygulama etki alanınıza özgü bir çerçeveye delege eder.

Salatalık, bir düzineden fazla farklı yazılım platformunu destekler. Size uygun olan Salatalık uygulamasını seçebilirsiniz. Her Salatalık uygulaması aynı genel işlevselliği sağlar ve ayrıca kendi kurulum prosedürlerine ve platforma özel işlevlere sahiptir.

Adımları ve Adım Tanımlarını Haritalama

Salatalığın anahtarı, Adımlar ve Adım Tanımları arasındaki eşleştirmedir.

Salatalık Uygulamaları

Aşağıda verilenler Hıyar uygulamalarıdır.

	Ruby / JRuby
	JRuby (Cucumber-JVM kullanarak)
	Java
	Harika
	.NET (SpecFlow kullanılarak)
	JavaScript
	JavaScript (Cucumber-JVM ve Rhino kullanarak)
	Clojure
	Gosu
	Lua
	PHP (Behat kullanarak)
	Jython
	C ++
	Tcl

Çerçeve Entegrasyonu

Aşağıda verilen Çerçeve uygulamalarıdır.

	raylar üzerinde yakut
	Selenyum
	PicoContainer
	Bahar Çerçevesi
	Watir

Kornişon, yazmak için kullanılan bir dildir Features, Scenarios, and Steps. Kornişonun amacı somut gereksinimler yazmamıza yardımcı olmaktır.

Somut gereksinimlerle neyi kastettiğimizi anlamak için aşağıdaki örneği düşünün -

Müşterilerin geçersiz kredi kartı bilgilerini girmeleri engellenmelidir.

Karşı

Bir müşteri, tam olarak 16 basamak uzunluğunda olmayan bir kredi kartı numarası girerse, formu göndermeye çalıştıklarında, doğru basamak sayısını bildiren bir hata mesajıyla yeniden görüntülenmelidir.

İkincisi belirsizliğe sahip değildir ve hataları önler ve çok daha fazla test edilebilirdir.

Kornişon, daha somut gereksinimler yaratmak için tasarlanmıştır. Gherkin'de yukarıdaki örnek şuna benzer:

Feature

Geçersiz kredi kartı bilgilerini girerken geri bildirim Feature Definition

Kullanıcı testinde, hata yapan birçok insan gördük Belgeler

Background True for all Scenarios Below

Given Satın almak için bir ürün seçtim

And Kredi kartı numaramı girmek üzereyim

Scenario - Kredi kartı numarası çok kısaScenario Definition

When 16 haneden kısa bir kart numarası giriyorum

And diğer tüm detaylar doğru

And Formu gönderiyorumSteps

Then form yeniden gösterilmelidir

And Bana doğru basamak sayısını bildiren bir mesaj görmeliyim

Kornişon Biçimi ve Sözdizimi

Gherkin dosyaları düz metin Dosyalarıdır ve .feature uzantısına sahiptir. Boş olmayan her satır bir Kornişon anahtar kelimesi ile başlamalı ve ardından istediğiniz herhangi bir metinle devam etmelidir. Anahtar kelimeler -

• Feature

• Scenario

• Verilen, Ne Zaman, Sonra, Ve Ama (Adımlar)

• Background

• Senaryo Özeti

• Examples

• "" "(Doküman Dizeleri)

• | (Veri Tabloları)

• @ (Etiketler)

• # (Yorumlar)

• *

Özellik

Featureanahtar sözcüğü, bir yazılım özelliğini açıklamak ve ilgili senaryoları gruplamak için kullanılır. Bir Özelliğin üç temel öğesi vardır -

• Anahtar kelime - Özellik.

• Özellik anahtar kelimesiyle aynı satırda sağlanan özelliğin adı.

• Birden çok satırı, yani Feature anahtar sözcüğünü içeren satır arasındaki tüm metni ve Senaryo, Arka Plan veya Senaryo Taslağı ile başlayan bir satıra yayılabilen isteğe bağlı (ancak şiddetle tavsiye edilen) bir açıklama.

Özellikler, bir ad ve açıklamaya ek olarak, senaryoların veya senaryo ana hatlarının bir listesini ve isteğe bağlı bir arka plan içerir.

A isimlendirmek gelenekseldir .featureDosyayı, Özelliğin adını alarak, küçük harfe dönüştürerek ve boşlukları altı çizili olarak değiştirerek. Örneğin,

feedback_when_entering_invalid_credit_card_details.feature

Sisteminizdeki Özellikleri tanımlamak için, "özellik yerleştirme şablonu" olarak bilinen şeyi kullanabilirsiniz.

Bir <kullanıcı türü> olarak <bazı hedeflere ulaşmak> için <a özellik> istiyorum

Açıklamalar

Gherkin belgelerinin bazı kısımlarının bir anahtar kelimeyle başlaması gerekmez.

Bir Özellik, senaryo, senaryo taslağını veya örnekleri izleyen satırlarda, hiçbir satır bir anahtar sözcükle başlamadığı sürece istediğiniz herhangi bir şeyi yazabilirsiniz. Açıklamaları eklemenin yolu budur.

Senaryo

Sisteminizin davranışını ifade etmek için, her Özelliğe bir veya daha fazla senaryo eklersiniz. O Özelliğin etrafındaki tüm davranışları tamamen belirtmek için Özellik başına 5 ila 20 senaryo görmek normaldir.

Senaryolar aşağıdaki düzeni izler -

• İlk bağlamı tanımlayın

• Bir olayı tanımlayın

• Beklenen bir sonucu açıklayın

Bir bağlamla başlıyoruz, bir eylemi açıklıyoruz ve sonucu kontrol ediyoruz. Bu adımlarla yapılır. Kornişon, bağlamların, eylemlerin ve sonuçların her birini adımlar olarak tanımlamak için üç anahtar kelime sağlar.

• Given - Bağlam oluştur

• When - Eylem gerçekleştirin

• Then - Sonucu kontrol edin

Bu anahtar sözcükler senaryonun okunabilirliğini sağlar.

Example

Scenario - Hesaptan para çekin.

• Given Hesabımda 100 dolarım var.

• When 20 $ talep ediyorum.

• Then 20 $ dağıtılmalıdır.

Birden fazla varsa Given veya When birbirinin altındaki adımlar, kullanabilirsiniz And veya But. Senaryoları detaylı bir şekilde belirlemenize izin verir.

Example

Scenario - Çalıntı kartı kullanarak para çekme girişimi.

• Given Hesabımda 100 dolarım var.

• But kartım geçersiz.

• When 50 dolar talep ediyorum.

• Then kartım iade edilmemelidir.

• And Banka ile iletişime geçmem söylenmeli.

Senaryolar oluştururken, 'her senaryonun anlamlı olması ve diğer senaryolardan bağımsız olarak yürütülebilmesi gerektiğini' unutmayın. Bu -

• Bir senaryonun başarı koşulunun, ondan önce başka bir senaryonun yürütülmüş olmasına bağlı olamaz.

• Her senaryo kendi özel bağlamını yaratır, bir şeyi yürütür ve sonucu test eder.

Bu tür senaryolar aşağıdaki faydaları sağlar -

• Testler daha basit ve anlaşılması daha kolay olacak.

• Senaryolarınızın sadece bir alt kümesini çalıştırabilirsiniz ve test setinizin bozulması konusunda endişelenmenize gerek kalmaz.

• Sisteminize bağlı olarak, testleri paralel olarak çalıştırabilir ve tüm testlerinizi gerçekleştirmek için harcadığınız süreyi azaltabilirsiniz.

Senaryo Özeti

Birkaç girdi veya çıktı içeren senaryolar yazmanız gerekiyorsa, yalnızca değerlerine göre farklılık gösteren birkaç senaryo oluşturabilirsiniz. Çözüm, senaryo taslağını kullanmaktır. Bir senaryo taslağı yazmak için,

• Senaryo anahat adımlarındaki değişkenler <ve> ile işaretlenmiştir.

• Değişkenler için çeşitli değerler bir tabloda örnek olarak verilmiştir.

Example

Hesap makinesine iki sayı eklemek için bir Özellik yazdığınızı varsayalım.

Feature - Ekle.

Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input    | output |
| 2+2      | 4      | 
| 98+1     | 99     |
| 255+390  | 645    |

Bir senaryo taslağı bölümünün ardından her zaman bir tablo için bir kap olan bir veya daha fazla örnek bölümü gelir. Tabloda, senaryo taslağı adımlarındaki değişkenlere karşılık gelen bir başlık satırı olmalıdır. Aşağıdaki satırların her biri, değişken değerleri doldurarak yeni bir senaryo oluşturacaktır.

SpecFlow, açık kaynaklı bir projedir. Kaynak kodu GitHub'da barındırılmaktadır. SpecFlow tarafından, uygulamanızdaki özellikler (kullanım senaryoları, kullanıcı hikayeleri) için bir kabul kriteri saklamak için kullanılan özellik dosyaları, Gherkin sözdizimi kullanılarak tanımlanır.

Kornişon formatı, Salatalık tarafından tanıtıldı ve diğer araçlar tarafından da kullanılıyor. Kornişon dili, GitHub'da bir proje olarak korunur -https://github.com/cucumber/gherkin

Özellik Öğeleri ve SpecFlow

Özellik öğelerinin temel özellikleri şunlardır:

• Özellik öğesi, unsur dosyası için bir başlık sağlar. Özellik öğesi, uygulamanızdaki ilgili özelliğin adını ve üst düzey bir açıklamasını içerir.

  • SpecFlow, özellik adından türetilen sınıf adı ile özellik öğesi için bir birim test sınıfı oluşturur.

  • SpecFlow, kabul kriterlerini temsil eden senaryolardan yürütülebilir birim testleri oluşturur.

• Bir özellik dosyası, özelliğin kabul testlerini açıklamak için kullanılan birden çok senaryo içerebilir.

  • Senaryoların bir adı vardır ve birden çok senaryo adımından oluşabilir.

  • SpecFlow, senaryonun adından türetilen yöntem adı ile her senaryo için bir birim test yöntemi oluşturur.

Çoklu Senaryo Adımları

Senaryoların birden çok senaryo adımı olabilir. Kabul testini oluşturan ön koşulları, eylemleri veya doğrulama adımlarını tanımlayan üç tür adım vardır.

• Farklı adım türleri, Given, When veya Then sırasıyla anahtar kelimeler ve aynı türden sonraki adımlar, And ve But anahtar kelimeler.

• Gherkin sözdizimi, bu üç tür adımın herhangi bir kombinasyonuna izin verir, ancak bir senaryo genellikle farklı bloklara sahiptir. Given, When ve Then ifadeler.

• Senaryo adımları metin kullanılarak tanımlanır ve DataTable olarak adlandırılan ek tablo veya DocString argümanları adı verilen çok satırlı metinler olabilir.

• Senaryo adımları, uygulamayı otomatikleştirmek için herhangi bir özel kodu yürütmenin birincil yoludur.

• SpecFlow, her senaryo adımı için birim test yöntemi içinde bir çağrı oluşturur. Çağrı, senaryo adımıyla eşleşen adım tanımını yürütecek olan SpecFlow çalışma zamanı tarafından gerçekleştirilir.

• Eşleştirme, çalışma zamanında yapılır, böylece oluşturulan testler, bağlama henüz uygulanmamış olsa bile derlenebilir ve yürütülebilir.

• Senaryo adımlarına tablolar ve çok satırlı argümanlar dahil edebilirsiniz. Bunlar adım tanımları tarafından kullanılır ve ya ek tablo ya da dize argümanları olarak aktarılır.

Etiketler

Etiketler, özelliklere ve senaryolara atanabilen işaretçilerdir. Bir özelliğe etiket atamak, etiketin özellik dosyasındaki tüm senaryolara atanmasına eşdeğerdir. Başında @ bulunan bir Etiket Adı, etiketi belirtir.

• Birim testi çerçevesi tarafından destekleniyorsa, SpecFlow etiketlerden kategoriler oluşturur.

• Oluşturulan kategori adı, etiketin adıyla aynıdır, ancak başında @ yoktur.

• Bu birim test kategorilerini kullanarak yürütülecek testleri filtreleyebilir ve gruplayabilirsiniz. Örneğin, önemli testleri @ önemli ile etiketleyebilir ve ardından bu testleri daha sık gerçekleştirebilirsiniz.

Arka Plan Öğeleri

Arka plan dili öğesi, bir özellik dosyasındaki tüm senaryolar için ortak bir ön koşul belirlemeye izin verir

• Dosyanın arka plan kısmı, senaryoların diğer adımlarından önce yürütülen bir veya daha fazla senaryo adımı içerebilir.

• SpecFlow, senaryolar için oluşturulan tüm birim testlerinden çağrılan arka plan öğelerinden bir yöntem oluşturur.

Senaryo Özetleri

Senaryo ana hatları, veriye dayalı kabul testlerini tanımlamak için kullanılabilir. Senaryo ana hatları her zaman bir senaryo şablonu spesifikasyonundan (<placeholder> sözdizimini kullanan veri yer tutuculara sahip bir senaryo) ve yer tutucular için değerler sağlayan bir dizi örnekten oluşur

• Birim testi çerçevesi destekliyorsa, SpecFlow senaryo ana hatlarından satır tabanlı testler oluşturur.

• Aksi takdirde, bir senaryo taslağı için parametreli birim testi mantık yöntemi ve her örnek kümesi için ayrı bir birim testi yöntemi oluşturur.

• Daha iyi izlenebilirlik için, üretilen birim testi yöntemi adları, senaryo ana hatlarından ve örneklerin ilk değerinden (örnekler tablosunun ilk sütunu) türetilir.

• Bu nedenle, örnek kümesindeki ilk sütun olarak benzersiz ve açıklayıcı bir parametre seçmek iyi bir uygulamadır.

• Kornişon sözdizimi, tüm örnek sütunların senaryo taslağında eşleşen yer tutuculara sahip olmasını gerektirdiğinden, testleri daha okunaklı bir şekilde adlandırmak için kullanılan örnek kümelerine rastgele bir sütun bile ekleyebilirsiniz.

• SpecFlow, adım bağlamalarını eşleştirmeden önce yer tutucu değiştirmeyi ayrı bir aşama olarak gerçekleştirir.

• Bu nedenle, adım bağlamalardaki uygulama ve parametreler, bunların doğrudan bir senaryo veya bir senaryo taslağı aracılığıyla yürütülüp yürütülmediğinden bağımsızdır.

• Bu, daha sonra adım bağlamalarını değiştirmeden kabul testlerinde başka örnekler belirlemenize olanak tanır.

Yorumlar

Satırı # ile başlatarak herhangi bir yerde özellik dosyalarına yorum satırları ekleyebilirsiniz. Bununla birlikte, şartnamenizdeki yorumlar kabul kriterlerinin yanlış belirtildiğinin bir işareti olabileceğinden dikkatli olun. SpecFlow, yorum satırlarını yok sayar.