BDD yeniyim, ama çok ilginç buldum ve bir sonraki projem BDD kullanarak geliştirmek istiyorum. Ve ekran googling izledikten sonra ben hala gerçek hayatta BDD hakkında bir sürü soru var.

1. Bildirim veya Zorunluluk senaryolar?

Gördüm-ne zaman-o zaman senaryolar en UI açısından () zorunlu olarak yazılmıştır.

Scenario: Login
     Given I am on the Login-page
     When I enter 'AUser' in the textbox 'UserName'
       And I enter 'APassword' in the textbox 'Password'
       And I click the 'Login' button
     Then I should see the following text 'You are logged in'

Bu testler son derece kırılgan buldum ve düğmeleri tıklayarak iş değeri hakkında hiçbir şey söylemezler. Kabus korumak için sanırım. Neden örnekler en zorunlu senaryoları kullanmak?

Scenario: Login (declarative)
     Given I am not logged in
     When I log in using valid credentials
     Then I should be logged in

Eğer bildirim tarzı tercih ederseniz, nasıl böyle şeyler tarif edersiniz 'ana sayfa' veya 'Ürün sayfası'?

• Tips for writing good specifications

2. Egzersiz UI değil mi?

Adımları en WatiN, ya da bu bakış kullanıcı noktası senaryoları uygulamak için kullanılan Beyaz bir şey gördüm uygulamaları. Tarayıcı düğmeleri başladı. Onun son derece yavaş ve kırılgan olduğunu düşünüyorum. Peki Sayfası nesnesi gibi bir şey testler daha az kırılgan yapmak için kullanabilirim. Ancak tahminim bir miktar bu. Özellikle karmaşık kullanıcı arayüzü ile masaüstü uygulamaları için.

Nasıl gerçek hayat projelerinde senaryoları - egzersiz UI, ya da/sunum test denetleyicileri ile uygulamak mı?

• Best way to apply BDD

3. Gerçek veritabanı veya değil?

Senaryo belli bir bölümünü uygulandığında, genellikle sistem olması bazı veri (alışveriş için bazı ürünleri örneğin uygulama) ihtiyacı var. Nasıl o gerçek bir veritabanı (tam uçtan uca test) veri ekleme veya denetleyicileri için depo taslakları sunan uygulamak mı?

Deneyimli cevaplar bekliyor!

GÜNCELLEME: soru Eklendi yararlı bağlantılar.

1. Declaritive doğru yolu, IMO. Eğer sayfa hakkında konuşuyorsun .SEO dosya adları, yanlış yapıyorsun. Hikayenin amacı geliştiriciler arasındaki iletişimi kolaylaştırmak ve-develoeprs olmayan. Olmayan geliştiriciler ürünleri umurunda değil.SEO ürün listesi önemsiyorlar. Sistemi olmayan geliştiriciler değer bulmak bir şey yok. Bunu yakalamak için çalışıyoruz ne.

2. Anlattıkların yüksek düzeyde uygulamak için gereken özellikler söyle. Sistem böyle yapması gerekir. Gerçekten bu yaptığın olmadığını anlamanın tek yolu aslında UI egzersiz için. Bana BDD SpecFlow hikayeler birim testleri yerine yapmayın, entegrasyon testleri sensin, onlar değil. Eğer bu kırarsan, senin yazılım iş alır değeri kırdın. Birim testleri kullanıcılar umurumda değil uygulama ayrıntılarını ve tek başına her parça test. Bunu size söyleyemem eğer A ve B gerçekten beraber her zaman (teori, pratik ilginç [okuyun: beklenmedik] şeyler yaparken aslında bu iki rol paylaşımı ile birbirlerine). Test sonunda otomatik son QA ile de yardımcı olabilir. Eğer fonksiyonel bir alana girerse, bunu biliyorsun, ve entegrasyon testleri kırdı belirlerken uygulamanın diğer alanlarında zaman geçirebilirler.

3. Bu biraz yanıltıcı. Melez bir yaklaşım yaptık. Yaptığımız kullanın veritabanı (entegre testlerden sonra tüm test sisteminin işleyişi gibi bir şey yerine, tek tek parçaları), ama yerine sıfırlama yapılandırmaları her zaman gittiğimiz Deleporter yerine bizim depoları ile Moqs zaman ihtiyacımız var. Tamam iş gibi görünüyor, ama kesinlikle artıları ve eksileri her iki şekilde de vardır. Hala büyük ölçüde kendimizi bu endam olduğumuzu düşünüyorum.