BDD - Test Odaklı Geliştirme
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 ile 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 test etmenin her aşamasında test senaryoları yazma zorunluluğu vardır. Bu, geleneksel test uygulamalarımızın bize öğrettiği şeydir ve 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 sebeple gözden kaçar:
Etabın tamamlanmasındaki gecikmeler.
Sıkı zaman programları.
Zamanında teslimata odaklanın, testi atlayın.
Ayrıca, Test-Son 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 elde edilememesi, bu aynı zamanda tekrarlanan işlerin kaybı 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ç, Önce Test yaklaşımı oldu.
İlk Test Yaklaşımı
Önce Test yaklaşımı, içten dışa (kodu yazın ve ardından test edin) geliştirmenin dıştan içe (testi yazın ve ardından 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 adımları 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ığı için, 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ılmıştı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 Agile uygulamalarının dışına çıkmıştır ve bunları ekipler için daha erişilebilir ve etkili, ç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