Patronunuz TDD'yi Takdir Etmeyecek: Bu Davranış Odaklı Geliştirme Örneği Deneyin

Test yapmak. Genellikle son dakikaya bırakılır, sonra zamanınız tükendiği, bütçenizin aşıldığı veya başka bir şey olduğu için kesilir.

Yönetim, geliştiricilerin neden "ilk seferde doğru yapamadıklarını" merak ediyor ve geliştiriciler (özellikle büyük sistemlerde), farklı paydaşlar sistemin farklı bölümlerini tanımladığında, kör adamların bir fil.

Ancak her projede ilk adımın oluşturulacak yazılımın veya özelliğin davranışları hakkında bir tartışma olması kaçınılmazdır. Bir müşteri veya iş adamı, geliştirme ekibinden birine gelir ve ne istediğini açıklar.

Bazen bu etkileşimler Çevik bir kullanıcı hikayesi şeklinde gelir. Bazen, Chris Fox'un geçen yılki blog girişinde olduğu gibi, tasarım belgeleri şeklinde gelirler. Ayrıca Keynote'ta akış çizelgeleri veya maketler veya hatta acele telefon görüşmeleri olarak gelebilirler.

Yalnızca bu iletişimlerden bir geliştirici, "sadece çalışan" bir sistem oluşturmaktan sorumludur. Bu, özellikle daha büyük sistemin dışında çalışan serbest çalışanlar için zordur.

Test neden kesiliyor?

Burada bariz bir boşluk var: eğer işletme sahibi sistemin davranışlarını başlangıçta öngördüyse, neden bu davranışların gerçekten işe yaradığını test etmek, atılan adımdır?

Cevap göz kamaştırıcı derecede basit olabilir: testler genellikle ortak sermaye olarak görülmez; “sadece mühendisler için” oldukları veya benzer şekilde tek bir departmana veya bir grup insana değer kattıkları için projeye değer verdikleri düşünülmez.

Bu paylaşılan sermayeyi, bu sistem davranışları listesini nasıl test ederiz? Yalnızca test odaklı geliştirmeyi (TDD) değil, davranış odaklı geliştirmeyi (BDD) benimseyerek.

BDD nedir?

Davranış odaklı geliştirme, kodunuzun uyguladığı iş davranışlarına, yani kodun arkasındaki "neden"e odaklanmalıdır. Ekip merkezli (özellikle çapraz işlevli) bir iş akışını destekler.

Çevik BDD'nin bir geliştirici ve Çevik ürün sahibi veya bir iş analisti birlikte oturup düz metin düzenleyicide bekleyen özellikleri (geliştirici tarafından daha sonra doldurulacak) yazdığında gerçekten iyi çalıştığını gördüm:

1. İş insanı görmek istediği davranışları sistemde belirtir.
2. Geliştirici , sistem hakkındaki anlayışlarına dayalı olarak sorular sorarken, aynı zamanda geliştirme perspektifinden ihtiyaç duyulan ek davranışları da yazar.

İdeal olarak, her iki taraf da bu yeni özelliğin mevcut özellikleri bozup bozmayacağını görmek için mevcut sistem davranışları listesine başvurabilir.

Bu basit hareketin bana bir geliştirici gibi düşünebileceğim yeterli kısıtlamalar sağladığını buldum: “bu testleri uygulamak zorunda olduğum göz önüne alındığında, bu beni/herkesi kodda uygulayabileceğim spesifikasyonlara nasıl kısıtlıyor”? Bekleyen spesifikasyonlar olduğundan, işbirliğinin yoğun olduğu bir ortamda hızlı ve kolay yazılırlar.

Bu işbirlikçi yaklaşım, özelliğin son kullanıcıya neler sağladığına odaklanmamı sağlıyor ve iş insanının tam orada olması beni uygulama hakkında değil davranış hakkında konuşmaya zorluyor. Bu, BDD ve TDD arasındaki farklılıkları vurgular.

Davranış Odaklı Geliştirme örneğini görelim

Senaryo: Rails'de uygulanan şirket muhasebe sisteminden sorumlu bir ekipte geliştiricisiniz. Bir gün, bir iş adamı, müşterilere bekleyen faturalarını hatırlatmak için bir hatırlatma sistemi uygulamanızı ister. Bu eğitimde BDD uyguladığınız için; (TDD'ye karşı), o iş insanı ile oturup davranışları tanımlamaya başlarsınız.

Metin düzenleyicinizi açarsınız ve iş kullanıcısının istediği davranışlar için bekleyen özellikler oluşturmaya başlarsınız:

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

Geliştirme sırasındaki davranışa bu odaklanma, testi yalnızca kodunuzun doğru olduğunu değil, doğru özelliği oluşturduğunuzu doğrulamak için de kullanışlı hale getirir. İfadenin, sistemin dahili uygulama dilinde değil, iş dilinde olduğuna dikkat edin. Bir belongs_to bir hesaba ait olduğunu görmez veya umursamazsınız, çünkü geliştirme ekibi dışındaki hiç kimse bununla ilgilenmez.

Bazı geliştiriciler, sistemdeki yöntemleri çağırarak, beklentileri şu şekilde ayarlayarak yerinde test senaryoları yazmayı tercih eder:

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

reminder_date ayarlamak için kodu henüz yazmadığımız için test takımı başarısız olacak.

Görünüşte başarısız olan özellikler

Başarısız özellikler yazan geliştiricileri anlıyorum, ancak iş adamı yanımdayken bu benim için hiç işe yaramadı. Yanlış iş adamı ya ayrıntılardan rahatsız olur ya da bu yeni bilgiyi alır ve geliştiricinin daha fazla bildiği şeyleri (uygun veritabanı tasarımı, kodun yeniden kullanımı) mikro yönetmeye çalışır.

Tecrübelerime göre, belirli bir davranışa ilişkin tek satırlık bir genel bakıştan fazlasını yazmak, iş adamını sıkacaktır. Bunu zamanlarını kötü kullanmak olarak görecekler veya bir sonraki davranışı akıllarındayken tarif etme konusunda endişeli olacaklardır.

BDD'nin TDD'den farkı nedir?

Buna Test Odaklı Geliştirme yaklaşımıyla farklı bir yoldan bakalım ve bekleyen testleri yazalım:

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

Bu testler yararlıdır, ancak yalnızca bir grup insan için yararlıdır: mühendisler. BDD, işlevler arası bir ürün ekibinin her üyesiyle iletişim kurmak için kullanışlıdır.

Bekleyen davranışları kullanarak bir BDD zihniyetindeyken kesinlikle test öncelikli geliştirme yapabilirsiniz. İlk önce testi yazın; sonra çalıştırın (kırmızı); sonra çalışmasını sağlayın (yeşil); sonra doğru yapın (refactor).

BDD topluluğunda, testin içindeki iddia kontrollerinin İngilizce gibi okunması için birçok çalışma yapıldı. İşte basmakalıp bir RSpec testi:

 a = 42 a.should == 42

Bu biçim, daha sonra okumayı kolaylaştırır. Ancak burada yaptığımızın bu olmadığını unutmayın - amaç, davranışları olabildiğince hızlı bir şekilde azaltmak ve 'özellik başına test edilmiş bir davranış' ilkesini uygulamaktır. İdeal olarak, bekleyen özellik başlığı size neyi test ettiğinizi söylemelidir.

BDD, sonuçlarınızı doğrulamanın süslü yollarıyla ilgili değildir; beklenen davranışları ekibin tüm üyeleri arasında paylaşmakla ilgilidir.

Davranış odaklı geliştirme, işbirliği ve iletişimle ilgilidir

Senaryomuza geri dönelim: şirket muhasebe sistemi üzerinde çalışmak.

İş insanı ile birlikte öğenin işlevselliğini gözden geçirirsiniz, sistemi kendi iç yapıları (nesnelerin dahili olarak nasıl bir araya geldiği) üzerinden analiz edersiniz ve onlar sistemi dışarıdan analiz ederler.

Bazı koşulları düşünür ve iş analistine aşağıdaki senaryolarda ne olduğunu sorarsınız:

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

Ve cevaplar alıyorsun. İş adamının, evcil hayvan fikrinde delik açmaya çalışmadığınızı veya aşırı bilgiçlik yapmadığınızı anlaması önemlidir.

Bu şekilde, Davranış Odaklı Geliştirme, işbirliğine yardımcı olmak ve iki departman arasında bir konuşma başlatmak için bir araçtır. Ayrıca, istenen bir özelliğin kapsamını netleştirmenin ve geliştirme ekibinden daha iyi tahminler almanın bir yoludur. Belki de belirli bir zaman noktasından 10 iş gününü hesaplamanın bir yolu olmadığını fark etmişsinizdir; bu, uygulamanız gereken ek, ayrı bir özelliktir.

Geliştiricilerin geliştirici değerlendirmeleri ("'gün' derken tam olarak ne demek istiyorsunuz?"), iş adamlarının kendi düşünceleri olacaktır ("Lütfen burada gecikmiş terimini kullanmayın, bu farklı bir anlama gelir"). Bir grubun ya da diğerinin harekete geçmesi ve bu iş mantığı davranış testlerini kendileri yazmaya çalışması (Salatalığın vaadi), her iki tarafın da değerli girdisini keser.

Ayrıca, Çevik İstemci artık fiziksel olarak odada olmadığında iyi bir vekildir: isteklerinin kağıt üzerinde, inşa ettiğiniz şeyin geliştirici analizi (ve çevirisi) ile karıştırılması.

Tasarım belgeleri

Daha önceki bir Toptal Blog gönderisi Chris Fox, özellikle bir projenin başlangıcında, tasarım belgelerinden bahsediyor. İş davranışlarını anlamak ve çıkarmak, sistemin biraz bilinebilir olduğu projelerden, başarmak için on yıllarca programcı yılı gerektiren ve yüzlerce veya binlerce davranış özelliğine sahip projelere doğru ölçeklenir.

Chris'in makalesi ayrıca öğelerin ekrandaki davranışlarından da bahsediyor ve bu, tasarımcılarla sürekli çeliştiğim bir alan: “Bu düğme loşken neye benziyor” veya “Bu, 11 ekranlarda nasıl görünüyor” çünkü bu sayfa açıkça 24" ekranlar için mi tasarlandı? İş insanı ile bu ileri geri, bir projenin grafik varlıklarında veya bir sayfa düzeninde boşluklar bulabilir.

Çok büyük çapraz işlevli ekiplerde, kendi endişeleri olan birçok ekip üyesi vardır: tasarımcılar, geliştiriciler, potansiyel olarak operasyonlardan biri, veritabanı yöneticisi - belki QA çalışanları (evet, TDD ve BDD'de herkes için bir yer var!), her biri kendi endişeleri ve soruları ile. BDD, bu işbirliğini test odaklı geliştirmeden daha fazla yönlendirebilir. "Veriler bu tablo için çok büyük olduğunda ne olur?" "Hmmm, bu pahalı bir sorgu olacak, bunu bir şekilde önbelleğe almak isteyeceğiz", "Bekle, kullanıcı tüm bu gizli bilgileri görmeli mi?", yalnızca bir geliştiriciden daha fazlası tehlikede olabilir ve bu yeni özellik hakkında soruları olan bir iş analisti

Davranış odaklı geliştirme, paylaşılan eserlerle ilgilidir

Paylaşılan yapı nedir?

Yazılım mühendisliğindeki "eserleri", projeyi veya proje ekibini tanımlayan ve altı ay sonra bulunabilecek potansiyel olarak fiziksel şeyler olarak düşünmeyi seviyorum. İyi eserler, şeylerin neden oldukları gibi olduğunu açıklar.

Koridor konuşmaları yapay değildir. Beyaz tahta çizimleri de değildir. Büyük uzun sınıf belgelerine veya tasarım belgelerine dönüşen beyaz tahta çizimleri - bunlar yapaydır. Toplantılardan alınan dakikalar da yapaydır.

Bir yapı, bir havuza veya paylaşılan alana kaydedilen bazı kaynak kodları ve bilet sistemindeki biletler veya dahili Wiki'deki notlar veya hatta kalıcı sohbet günlükleridir.

Paylaşılan eserler bence en iyi eserlerdir . Bir şeyin neden böyle olduğunu değil, uygulamada neden var olduğunu da gösterirler.

Bunları BDD'de nasıl kullanıyorsunuz?

Davranışlar, paylaşılan bir ekip eseri olmalıdır - testler yalnızca programcılar için yoğun bir çalışma olmamalıdır! Tüm ekibin mevcut özellikleri kolayca görüntüleyebileceği bir sisteme sahip olmak en iyisi olsa da (belki dağıtım sistemi de davranış listesini sitenin özel bir alanına veya bir wiki'ye çıkarır ve kaydeder), ayrıca her seferinde manuel olarak da yapabilirsiniz. sürat koşusu.

Oyunun adı, "geliştiricilerin iş değerini daha hızlı sunmak, bölümler arası işbirliği yapmak ve daha iyi tahminler yapmak için ihtiyaç duyduğumuz özellikleri oluşturmasına yardımcı olun".

Sistemin ne yaptığına dair şirket çapındaki bu anlayış da bir tür sermayedir. Kodun “nasıl”ının “neden”idir.

Çözüm

Müşterilere teslim edilen buggy yazılım sorununu nasıl çözeriz? Testin "sadece geliştiricilerin umursadığı" bir şey olarak görülmediğinden emin olarak.

Bir sistemin ihtiyaçlarını tanımlamanın ve anlamanın, kod doğruluğunun ötesinde tonlarca faydası vardır: departmanlar arası diyalog kurmak ve tüm paydaşların endişelerinin karşılandığından emin olmak (sadece büyük süslü unvanlara sahip paydaşların değil). Bu ihtiyaçları en baştan anlamak için davranış odaklı geliştirmeyi kullanmak ve tüm ekibin önemsediği harici iş davranışlarını test etmek - bu , kaliteli bir proje sağlamanın harika bir yoludur.