TDD (Test Odaklı Geliştirme) yapmazsanız, kendinizi (veya ekibinizi) "Çevik" olarak doğru bir şekilde çağırmanız mümkün mü?

Evet, evet, evet, milyon kere evet.

Çevik bir felsefe, TDD belirli bir metodolojidir.

Ben olmak isteseydim gerçekten onların savunucuları olan ayrıntılarıyla açıklayacağımız - seçici Ben sadece orada xDD epeyce varyasyonlar işaret olabilir değil TDD - ama o hala büyük ölçüde testi ilk böylece hile yapmak olurdu ile bağlıdırlar.

Öyleyse şunu söyleyelim - "ilk önce test et" geliştirmesini yapmadan çevik olabilirsiniz (scrumun çalışma biçimine bakın - hiçbir yerde kod yazmanın nasıl olduğu hakkında özel bilgiler yoktur). Bir kanban tahtasına bakın, her türlü çevik metodolojiye bakın.

Birim testleri ister misiniz? Elbette, her türlü nedenden ötürü - ve birim testleri olmadan çevik olamayacağınıza dair bir iddiada bulunabilirsiniz - (olabileceğinden şüpheliyim olsa da) - ama önce olmak için onları yazmak zorunda değilsiniz. çevik.

Ve son olarak, genel olarak ilk dev felsefenizden bağımsız olarak, ilk önce testi yapmak için çevik ve güçlü argümanlar olmadan Test Yapabilmeniz eşit derecede doğrudur .

Öyle görünüyor ki (daha fazla SOLID temsilcisi ile) benzer bir görüşü var ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS TDD ve OOD olmadan Çevik yapmak imkansız olsa da, zor. TDD olmadan iterasyon oranı ...

(Tweet’teki bağlantı, LinkedIn’in tam cevabıdır)

"Çevik olmak" basitçe çevik manifesto'nun değerlerine ve ilkelerine bağlı kalmak anlamına gelir . Bu belgedeki hiçbir şey TDD'den ve hatta bu konuda birim testinden bahsetmiyor.

Yani evet, TDD veya ünite testi yapmadan çevik olabilirsiniz.

Gerçi tavsiye etmem ...

Evet ,

Çevik değerlerden birine bakın:

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

Bu zaten cevap vermeli. TDD belli bir metodoloji, bir süreçtir. Aslında, çevik gelişim süreçlerinde kullanılabilecek bir süreç, ama daha fazlası değil. Sanırım artık TDD'nin çevikken en son teknoloji ürünü olduğunu düşünüyorum. Ancak, TDD'nin başka uygulamalarla değiştirilmiş olmasına rağmen, çevik kavramının hala devam edebileceğini düşünüyorum.

Ben şöyle özetlerdim:

• Bugün TDD, çevik olmak için bir standart dışı

• TDD'siz çevik olmanın yolları olabilir

Diyorum

Hayır [çeşit]

Özgün kaynağa geri dönerseniz, http://en.wikipedia.org/wiki/Extreme_Programming TDD bu süreç için esastır; Testler şartnamelerin yerine ve şelale kullanım koşullarının yerine geçmekte, canlı dokümantasyon ve işlevsellik örnekleri olarak hizmet vermektedir. Bunlar vazgeçilmezdir.

Bununla birlikte, şu an etrafta yüzen çok farklı 'çevik' lezzetleri var, bunlardan birinin TDD'den kaçması tamamen mümkün

EDIT: @ Murph'un soruyu yorumlaması tercih edilen gibi görünüyor. Heck, onu bile oyladım, bu iyi bir cevap. Bununla birlikte , Çevik Manifesto'nun bir geliştirme metodolojisi değil, bir dizi ilke olduğu fikrimi koruyorum. Faydaları sağlayan uygulamaları gerçekten uygulamadan "oh evet çevikim" demekte fayda görmüyorum. Özellikle:

Çalışan yazılım, ilerlemenin birincil ölçüsüdür.

ve

Çevik süreçler sürdürülebilir kalkınmayı teşvik eder. Sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak sabit bir hızda kalabilmelidir.

Bana göre, bu iki ilke TDD gerektirmediği anlamına gelir - en azından onsuz onları elde etmenin başka bir yolu olmadığını biliyorum!

EDIT 2: evet, teknik olarak testleri sonradan yazabilirsiniz; ama yine de ilk test / TDD'yi temel görüyorum. Onsuz "çevik" olamayacağınız için değil, onunla daha çevik olacağınız için değil. Test-ilk / test odaklı, testten sonraki / test sonrasındaki testten çok daha verimli bir yaklaşımdır. Test açıklamaları vardır gereksinimleri . Onları daha sonra ertelemeyin ;-)

EDIT 3: Sonunda, Murph'un çok iyi yazılmış cevabı hakkında beni bu kadar rahatsız eden şeyin ne olduğunu öğrendim. Bu, aslında yapmadan "Çevik" olabileceği fikri . Ve "yapıyor" (yukarıda gösterildiği gibi) hemen hemen TDD gerektirir.

Kesinlikle, çevik manifestoya bağlı kalarak çeviksiniz . Uygulamada, iyi bir test kapsamı olmadığı sürece bir kod tabanı çevik değildir. TDD'yi yapabilir ve işlevsellik geliştirmeden önce / sırasında testleri yazabilir veya geliştirildikten sonra işlevsellik için testler yazabilirsiniz. TDD'yi yapmak genellikle daha kolay ve daha etkilidir.

Çevik olabilirsiniz, ancak iyileştirme için muhtemelen yer vardır.

Çevik ilkelerden biri değişime cevap verebilmeniz gerektiğidir. Bu, ne inşa etmeniz gerektiğini önceden bilmediği anlamına gelir. Bir şelale sürecini takip ediyor olsaydınız, tam olarak neye ihtiyacınız olduğunu x ay önceden bilirdiniz ve bireysel yazılım bileşenleri tasarlayabilirsiniz, böylece her biri daha büyük bir programa katılarak nihai ürüne ulaşırdı (en azından bunu düşünürdünüz. öyleydi). Ancak çevik, nihai ürünün ne olduğunu bilmediğinizi belirttiğinden, hangi kodun ne için kullanılacağını ve daha da önemlisi ne zaman değiştirileceğini asla bilemezsiniz.

Bu nedenle, zaten oluşturduğunuz özelliklerin kod tabanı değiştirilirken çalışmaya devam ettiğinden emin olmak için kapsamlı bir test paketi gerekir.

Ancak bu TDD değildir. Kodları yazdıktan sonra testleri yazarsanız, TDD değildir. Ancak TDD başka bir yönüyle yardımcı oluyor, aşırı üretimi önlüyor.

Kendi çevik ekibimde, geliştiricilerle, projenin ilerleyen bölümlerinde faydalı olacağına inandıklarının kodunu yazarak mücadele ediyorum. Bu şelale gelişiminde büyük olasılıkla iyi olurdu, çünkü gelecek x ay boyunca proje planındaki bir şeye destek veriyorlardı.

Ancak çevik prensiplere uyuyorsanız bu kodu yazmamalısınız, çünkü gerekli olup olmadığı konusunda hiçbir fikriniz yok. Gelecek hafta için planlanan özellik aniden süresiz olarak ertelenebilir.

TDD prensibini doğru izlerseniz, bir test bu kod satırını belirlemeden önce tek bir kod satırı bulunamaz (şahsen test etmeden bazı önemsiz kodlar yazabilirim) ve kabul testini yazmaya başladığınızda İstenilen özellikleri sağlamak için tam olarak ne gerekiyorsa.

Bu yüzden TDD aşırı üretimden kaçınmaya yardımcı olarak ekibin mümkün olduğu kadar etkili olmasını sağlıyor, ki bu da temel bir çevik prensip.

Çalışan yazılım, ilerlemenin birincil ölçüsüdür

TDD (test odaklı geliştirme) yapmadan Çevik olabilir misiniz?

Kısa cevap: Evet.

Daha uzun cevap: Bu soruya zaten çok iyi cevaplar ve çok iyi referanslar var. Bu noktaları tartışmaya çalışmayacağım.

Tecrübelerime göre Agile, eldeki proje için doğru Yalınlığı seçmekle ilgilidir. Yalınlık derken ne demek istiyorum? Ve neden bu cevaba cevap veriyorum?

Yalın, yönteminizden mümkün olan her şeyi kesmek anlamına gelmez. Meslektaşlarımızdan birinin belirttiği gibi, davranışlarınıza TDD veya Ünite Testi dahil etmek zorunda değilsiniz. Ancak, proje bağlamında kendinizi bulursanız, yararlı olabilir veya olmayabilir.

AK'de bulunan büyük bir isimsiz perakendecinin tedarik zincirini düşünelim. Tüketici var. Dükkana giriyorlar. Mağaza çeşitli ürünleri kamyonla alıyor. Kamyonlar, muhtemelen, bu ürünleri bir depodan alıyorlar. Depo, çeşitli üreticilerin gönderileri ile doldurulur. Üreticiler ise bütün tedarik zincirlerine kendileri sahipler.

Yukarıdaki tedarik zincirinde nakliye için genel müdüre filosunda 10'dan az kamyon olduğu her yıl için yıllık 1 milyon dolarlık bonus alacağı söylenirse ne olur? Filoyu hemen 9 kamyona kesecek. Bu "korkunç" senaryoda, bu depoda depolanan malların miktarını yükseltir (bu düğümde maliyeti artırır). Ve mağaza cephelerini "aç bırakacak".

Bu nedenle, genel tedarik zinciri, bütünü dikkate almadan yerel optimizasyona izin verilirse zarar görür.

TDD ve UT'ye dön. TDD bir gereksinimler ifade mekanizmasıdır. Sistem bu kısıtlamaları yerine getirmelidir. Yeterince adil. TDD, Case Drive Development'in gereksinim davranışını veya User Story Driven Development'in gereksinim davranışını değiştirebilir. Birim Testi ve Gereksinimler iş yüklerini birleştirmenin "eğilerek" faydası vardır. Genel iş yükünün azaltılması bir avantajdır. Bu, genel tedarik zincirinin iş yükünün artması halinde değildir (kaliteyi düzeltelim).

Ve şunu sordunuz: TDD yapmadan çevik olabilir misiniz (test odaklı geliştirme)?

Tabi ki yapabilirsin. Farklı ve belki de daha iyi bir soru şudur: - Bu projeye TDD uygularsam, genel olarak daha verimli bir yazılım teslimatı mı yoksa daha az verimli mi sonuçlanır?

Favori bir yazarı alıntı yapmak için ... JRR Tolkien

Yüzüklerin Efendisi. Yüzüklerin Bursu. Pg 94 'Ayrıca söyleniyor', dedi Frodo, 'Avukatlar için elflere gitme, çünkü hem hayır hem de evet.'

Yani, sonunda, ... buna bağlı. Soruya cevap vermelisin. Hangi yol sizi en verimli şekilde istediğiniz hedefe yönlendirecektir?

TDD'ye veya TDD'ye değil. Bu soru kalır. :-)

Not: Bu cevabı da başka bir sitede yayınladım. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

Bir kale mühendisliği ile karşılaştırıldığında.

Çevik Kale

Çevik'i kullanarak bir kale inşa etseydin. Belirli işlevlere sahip bölümler yazacak ve kullanıcıyı gelecekteki tasarımını kullanıcının tepkilerine göre ayarlayarak işlevsel parçaları kullanmaya teşvik edeceksiniz. Yani, zindanı inşa ediyorsun ve zindan bekçisi ile iletişim kuruyorsun, zeminin ve zindanın sağladığı temeli test edersin. Parapetleri kurup gece nöbetçilerine sorun olup olmadığını sor. Duvarları inşa ettin ve askerlerin savunma değerini test etmesini sağladın. Mutfağı inşa edersin ve aşçıların bakmasını isterdin. Ve bu süreçte, güncel yapıya ek olarak bugüne kadar her bölüm işlev görecektir. Yani zindanı bitirdiğinde, mahkumları içeri sokabilirsin. Ama kaleyi nihayet bitirdiğinde, mahkumların kaçtıklarını anlarsın.

TDD Kalesi

TDD ile mahkumlarla görünüp kaçtıklarını görün. Öyleyse hapishane hücrelerini kaçamayana kadar yazarsınız. Daha sonra, gereksiz hücreleri temiz bir şekilde temizleyerek ve yanlış konumdaki çubukları kaldırarak kodu tekrar gözden geçirin ve tekrar test edin. Mahkumlar kaçmadı. Hapishaneyle iletişim kurmak zorunda değilsin. Ve hepsini bitirdikten sonra tüm kaleyi teslim edebilirsin. Bu noktada, hapishane zindanın daha fazla hücreye ihtiyaç duyduğunu ve şimdi daha fazla vakfı kazmanız gerektiğini söylüyor.

Çevik TDD Kalesi

Agile ve TDD'yi birleştirirseniz. Mahkumların kaçıp kaçmadığını görürsünüz, sonra hapishaneye neye ihtiyacı olduğunu sorarsınız. Daha fazla hücreye ihtiyacın olduğunu söylüyor. Mahkum gibi davranmak için bazı rastgele insanları alır ve kaçarlarsa görürsün. Olmazlarsa, onu hapishaneye gösterirsiniz, ve o mutludur. Sonra parapetleri inşa etmeye başlarsın.

Sonuç

Yani her ikisi de farklı problemleri çözer. Agile, ürünün uyum sağlamanın en kolay olduğu noktada geliştiğini gördüklerinde, kullanıcıların ihtiyaçlarını keşfetmeye dayalı değişen gereksinimlere yardımcı olur. Genel tasarımdan ayrılan sağlam eklemelerin serbest bırakılmasını içerir.

TDD başarısızlık beklentisini çözüyor. Başarısızlığı en kolay çözüme kavuşturan bir noktada meydana geldiği anda başarısızlığı keşfetmek ve düzeltmek. Genel tasarıma göre ayrılmış bağımsız birleştirilmiş kod birimlerinin test edilmesini içerir.

TDD'yi Agile'nin bir uzantısı olarak görmek kolaydır, çünkü her ikisi de aynı modeli izler, birim odaklı ilerleme ve gözden geçirme. Aradaki fark, Çevik'teki birimlerin harici olarak bir bütün olarak işlev görmesi, TDD'deki birimler bir parça olarak işlev görmesi ve dış inceleme için işleyen bir ürün üretmemesi olabilir. Her iki süreç de farklı ihtiyaçları yönetir (kullanılabilirlik vs. doğruluk). Her ikisi de birimler halinde gelişme süreci üzerinde işlediğinden, her iki inceleme süreci de benzer noktalarda gerçekleşebilir ve TDD daha iyi bölünmüştür.

notlar

• Tek başına birim testlerinin yapılması TDD kullandığınız anlamına gelmez. TDD, testin üretilen üniteden önce yapılmasını ve üniteyi onaylamak için geliştirdiğiniz testin kullanılması anlamına gelir. TDD'siz birim testi, önceden oluşturulmuş işlevselliği geçersiz kılmadığınızdan emin olmak için kullanılabilir.
• Sprintler ve diğer toplantılar yapmak sizi çevik yapmaz. Belli tezahürün amaçları seni çevik yapar. İnsanları süreçler konusunda iyilik taahhüdünü yerine getirmeksizin şelale hedeflerini çalışma birimleriyle parçalara ayırabilirsiniz.
• TDD ve Agile tanımı ile. Birim testleriniz, teslim edilemeyen birimleri yönetecek ve böylece TDD, Çevik'ten daha hızlı devredecektir. Her ikisini de kullanırsanız, Çevik döngüleriniz bir veya daha fazla TDD döngüsü içerecektir (eğer her ünite test edilmişse).
• Anladığım kadarıyla: Kullanıcıya teslim edilebilir / anlamlı bir birim geliştirmeyi başaramazsanız Agile'den başarısızsınız. Ünite, ürünü hızlandırsa bile anlamlı olabilir. Ancak Agile, bakımı kolaylaştıran yeniden düzenlemeyi nasıl açıklar? Buna cevap verecek kadar kapalı değildim.
• Birim testini geçerek TDD'de başarısız oluyorsunuz. Özelliği doğru şekilde üretmeyen kod üretmek.

Çevik, sizi her seferinde program ve kalite risklerini ele almaya ve azaltmaya zorlar. yani TDD'nin Çevik olduğu düşünülmesine gerek yoktur .

Bununla birlikte, TDD, özellikle çok sayıda yineleme veya insan içeren bir proje için kalite risklerini azaltmak için muazzam bir tekniktir. Böyle bir projede TDD, erken dönem yinelemelerde zaman çizelgesi riski ekleyecektir, çünkü siz de test senaryoları yazmalısınız. Ancak, TDD daha sonraki yinelemelerde büyük maliyet tasarrufu sağlar çünkü kalite risklerini sürekli olarak azaltır. yani TDD önerilir.