it-swarm.dev

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

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

44
CraigTP

Evet, evet, evet, milyonlarca kez evet.

Çevik bir felsefe, TDD spesifik bir metodolojidir.

Eğer gerçekten seçici olmak istersem, sadece savunucularının derinlemesine açıklayacağı xDD'nin birkaç varyasyonu olduğunu belirtebilirim: değil TDD - ama bunlar hala büyük ölçüde teste bağlıdır, böylece hile olur.

Öyleyse şunu söyleyelim - "önce test et" geliştirme yapmadan çevik olabilirsiniz (scrum'un çalışma şekline bakın - hiçbir yerde kod yazma ile ilgili ayrıntılar yoktur). Bir kanban panosuna bakın, her türlü çevik metodolojiye bakın.

Birim testleri ister misiniz? Tabii ki, her türlü nedenden ötürü - ve birim testler olmadan çevik olamayacağınızı iddia edebilirsiniz (olabileceğinizden şüphelenmeme rağmen) - ama önce onları yazmak zorunda değilsiniz çevik.

Ve son olarak, Test First without eşit derecede doğru, genel geliştirme felsefenizden bağımsız olarak ilk önce test yapmak için çevik ve güçlü argümanlar.


Öyle görünüyor ki (daha fazla SOLID rep) benzer bir görüşe sahip ...

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

@unclebobmartin: http://t.co/huxAP5cS TDD ve OOD olmadan Agile yapmak imkansız olmasa da, zor. TDD olmadan yineleme oranı ...

(Tweet'deki bağlantı LinkedIn'deki tam yanıttır)

50
Murph

"Çevik olmak", çevik manifesto değerlerine ve ilkelerine bağlı kalmak anlamına gelir. Bu belgedeki hiçbir şey TDD'den, hatta bu konu için birim testinden bahsetmez.

Yani evet, TDD veya birim testi yapmadan çevik olabilirsiniz.

Ben olsa tavsiye etmem ...

19
Martin Wickman

Evet,

Çevik değerlerden birine bakın:

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

Bu zaten cevaplamalı. TDD belirli bir yöntemdir, bir süreçtir. Gerçekten de çevik gelişim süreçlerinde kullanılabilecek bir süreç, ama daha fazlası değil. Bence belki TDD çevikken artık en son teknoloji. Ancak, belki TDD'nin yerini başka uygulamalarla değiştirmiş olsa bile, çeviklik kavramının hala devam edebileceğini düşünüyorum.

Ben şöyle özetlemek istiyorum:

  • Bugün TDD çevik olmak için bir standarttır

  • TDD olmadan çevik olmanın yolları olabilir

11
FabianB

Diyorum

Hayır [çeşit]

Orijinal kaynağa geri dönerseniz http://en.wikipedia.org/wiki/Extreme_Programming TDD sürecin temelini oluşturur; testler, gereksinimlerin şartnamelerinin ve şelalenin kullanım durumlarının yerini alır, canlı belgeler ve işlevsel örnekler olarak hizmet eder, vb. Bunlar vazgeçilmezdir.

Ancak, 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 soru gibi görünüyor. Heck ben bile iptal ettim, bu iyi bir cevap. Ancak, Çevik Manifesto'nun bir geliştirme metodolojisi değil, bir dizi prensip olduğu fikrimi koruyorum. Faydaları getiren uygulamaları uygulamadan "oh evet çevikim" demenin hiçbir faydasını 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 kalmalıdır.

Bana göre, bu iki ilke TDD gerektirmiyorsa - en azından onsuz bunları başarmanın başka bir yolunu bilmiyorum!

EDIT 2: evet, teknik olarak testleri daha sonra yazabilirsiniz; ama yine de ilk test/TDD'yi temel olarak görüyorum. O olmadan "çevik olamaz" değil, onunla daha fazlası çevik olacağınız için değil. Önce test/test odaklı, test-sonrası/test-sonrası düşünceden çok daha verimli bir yaklaşımdır. Test açıklamaları gereksinimlerdir. Onları ertelemeyin ;-)

DÜZENLEME 3: Sonunda Murph'un çok iyi yazılmış cevabı hakkında beni neyin rahatsız ettiğini anladım. Bu aslında yapıyor olmadan "Çevik" olabileceği fikridir. Ve "bunu yapmak" (yukarıda gösterildiği gibi) TDD gerektirir.

5
Steven A. Lowe

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

Çevik prensiplerden biri de değişime cevap verebilmenizdir. Bu, ne inşa etmeniz gerektiğini önceden bilmediğiniz anlamına gelir. Bir şelale sürecini izliyorsanız, tam olarak neyi inşa etmeniz gerektiğini x ay önceden bilirsiniz ve her biri son ürüne ulaşarak daha büyük bir şemada yer almaları için ayrı ayrı yazılım bileşenleri tasarlayabilirsiniz (en azından öyleydi). Ancak çevik, nihai ürünün ne olduğunu bilmediğinizi belirlediğinden, kodunuzun 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ştirildikçe çalışmaya devam ettiğinden emin olmak için kapsamlı bir test paketine ihtiyacınız vardır.

Ama bunun kendisi TDD değil. Testleri kodu yazdıktan sonra yazarsanız, TDD değildir. Ancak TDD başka bir yöne yardımcı olur, aşırı üretimi önler.

Kendi çevik ekibimde, projenin ilerisinde faydalı olacağına inandıkları kod yazan geliştiricilerle uğraşıyorum. Önümüzdeki x ay için proje planında bir şey için destek ekledikleri için, muhtemelen iyi olacak şelale gelişimi olsaydı.

Ancak çevik ilkeleri takip ediyorsanız bu kodu yazmamalısınız, çünkü bunun gerekli olup olmayacağı hakkında hiçbir fikriniz yoktur. Gelecek hafta için planlanan özellik aniden süresiz olarak ertelenebilir.

TDD prensibini doğru bir şekilde izlerseniz, bir test bu kod satırını belirtmeden önce tek bir kod satırı bulunamaz (kişisel olarak test etmeden bazı önemsiz kodlar yazabilirim) ve kabul testini yazarak başlarsanız, yalnızca gerekli özellikleri sağlamak için tam olarak ne gerekiyorsa.

Böylece TDD, aşırı üretimden kaçınmaya yardımcı olur ve ekibin mümkün olduğunca etkili olmasına izin verir, bu da aynı zamanda temel bir çevik ilkedir.

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

2
Pete

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

2
Alb

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

Kısa cevap: Evet.

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

Deneyimlerime göre, Agile eldeki proje için doğru Yalınlık seviyesini seçmekle ilgilidir. Yalınlık ile ne demek istiyorum? Ve neden bu cevaba getiriyorum?

Yalın, yönteminizden mümkün olan her şeyi kesmek anlamına gelmez. Çalışma arkadaşlarımızdan birinin belirttiği gibi, davranışlarınıza TDD veya Birim Testi dahil etmek zorunda değilsiniz. Bununla birlikte, proje bağlamında kendinizi bulursunuz, yararlı olabilir veya olmayabilir.

AK'de bulunan büyük bir isimsiz perakendecinin tedarik zincirini düşünelim. Tüketici var. Mağazaya giderler. Mağaza kamyon aracılığıyla çeşitli ürünler alır. Kamyonlar, muhtemelen bu ürünleri bir depodan alıyor. Depo, çeşitli üreticilerin gönderileri ile doldurulur. Üreticiler de tüm tedarik zincirlerine sahipler.

Yukarıdaki tedarik zincirinde nakliye genel müdürüne, filoda 10'dan az kamyonu olduğu her yıl için yıllık 1 milyon dolar bonus alacağı söylendiğinde ne olur? Filoyu hemen 9 kamyona parçalayacak. Bu "korkunç" senaryoda, bu depoda depolanan mal miktarını artıracaktır (bu düğümde maliyeti artırır). Ve mağaza cephelerini "aç bırakacak".

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

TDD ve UT'ye geri dön. TDD bir gereksinim ifade mekanizmasıdır. Sistem bu kısıtlamalara uymalıdır ZORUNLU. Yeterince adil. TDD, Use Case Drive Development'ın gereksinim davranışının veya User Story Driven Development'ın gereksinim davranışının yerini alabilir. Birim Testi ve Gereksinimler iş yüklerini bir araya getirmenin "eğilerek" yararına sahiptir. Toplam iş yükünün azaltılması bir avantajdır. Toplam tedarik zincirinin iş yükü arttırılırsa (kaliteyi düzeltelim) değil.

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

Tabi ki yapabilirsin. Farklı ve belki de daha iyi bir soru şudur: - Bu projeye TDD uygularsam, genel olarak daha verimli bir yazılım dağıtımı mı yoksa daha az verimli mi olacak?

Favori bir yazarı alıntılamak için ... J.R.R. Tolkien

Yüzüklerin Efendisi. Yüzük Kardeşliği. Sf 94 'Ve aynı zamanda' söyleniyor 'dedi Frodo,' Avukat için elflere gitme, çünkü hem hayır hem de evet. '

Sonunda, ... duruma göre değişir. Soruyu cevaplamalısınız. Hangi yol sizi en verimli şekilde hedeflerinize götürecektir.

TDD'ye ya da değil TDD'ye. Asıl soru bu. :-)

Not - Bu yanıtı başka bir sitede de yeniden gönderiyorum. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

1
M Kevin McHugh

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

Çevik Kale

Eğer Agile kullanarak bir kale inşa edecek olsaydın. Belirli işlevlere sahip bölümler yazar ve kullanıcıyı fonksiyonel parçaları kullanmaya teşvik eder, gelecekteki tasarımı kullanıcının tepkilerine göre ayarlarsınız. Yani, zindanı inşa ediyorsun ve zindan bekçisi ile iletişim kuruyorsun, toprak ve zindan tarafından sağlanan temeli test edeceksin. Korkulukları inşa eder ve gece bekçilerine iyi olup olmadığını sorarsınız. Duvarları inşa edersiniz ve askerlerin savunma değerini test etmesini istersiniz. Mutfağınızı inşa eder ve aşçılara bakmasını istersiniz. Ve bu işlem sırasında, bugüne kadar her bölüm mevcut yapıya ek olarak işlev görecektir. Yani zindanı bitirdiğinde, mahkumları içeri alabilirdin. Ancak kaleyi sonunda bitirdiğinizde mahkumların kaçtığını öğrenirsiniz. Şimdi zindana geri dönmeli ve daha kalın çubuklara ihtiyacınız olduğunu öğrenmelisiniz, ancak kapılar çubukları tutacak kadar derin değil ve menteşeler daha büyük kapıları desteklemiyor.

TDD Kalesi

TDD ile mahk prisonmlara gelip kaçıp kaçmadıklarını görüyorsunuz. Sonra kaçamayana kadar hapishane hücrelerini yazarsınız. Ardından, gereksiz hücreleri temizleyen ve yanlış konumdaki çubukları temizleyen kodu yeniden düzenleyip yeniden test edersiniz. Mahkumlar kaçmadı. Jailor ile iletişim kurmanıza gerek yok. Ve tüm kaleyi bitirdikten sonra tüm kaleyi teslim edebilirsin. Bu noktada jailor, zindanın daha fazla hücreye ihtiyacı olduğunu söylüyor ve şimdi vakfın daha fazlasını kazmanız gerekiyor.

Çevik TDD Kalesi

Çevik ve TDD'yi birleştirirseniz. Mahkumların kaçıp kaçmadığını görürsünüz, sonra jailor'a neye ihtiyaç duyulduğunu sorun. Daha fazla hücreye ihtiyacın olduğunu söylüyor. Mahkum gibi davranmak ve kaçıp kaçmadıklarını görmek için bazı rasgele insanları alırdın. Eğer yapmazlarsa, o zaman jailor'a gösterirsin ve o mutlu olur. Sonra korkulukları inşa etmeye başlarsınız.

Sonuç

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

TDD başarısızlığı öngörme problemini çözer. Arızayı, işlemin düzeltmenin en kolay olduğu bir noktada gerçekleştiği için bulma ve düzeltme. Genel tasarımdan ayrılan kararlı ayrıştırılmış kod birimlerinin test edilmesini içerir.

TDD'yi Agile'ın bir uzantısı olarak görmek kolaydır, çünkü ikisi de aynı modeli, birim odaklı ilerlemeyi ve incelemeyi takip eder. Fark, Agile'daki birimlerin harici olarak bir bütün olarak işlevini yerine getirmesi, TDD'deki birimlerin bir parçası olarak işlev görmesi ve harici inceleme için işlevsel bir ürün üretmemesidir. Ve her iki süreç de farklı ihtiyaçları yönetir (kullanılabilirlik ve doğruluk). Her ikisi de birimler halinde geliştirme süreci üzerinde işlev gördüğünden, her iki inceleme süreci de benzer noktalarda gerçekleşebilir ve TDD daha ince bölünür.

Notlar

  • Yalnızca birim testlere sahip olmak, TDD kullandığınız anlamına gelmez. TDD, testin üretilen üniteden önce yapılması ve üniteyi onaylamak için geliştirdiğiniz testin kullanılması anlamına gelir. TDD'siz birim testi, daha önce oluşturulmuş işlevselliği geçersiz kılmadığınızdan emin olmak için kullanılabilir.
  • Sprint ve diğer toplantılar yapmak sizi çevik yapmaz. Manifest'in hedefleri sizi çevik yapar. İnsanları süreçler üzerinde tercih etme taahhüdünü yerine getirmeden şelale hedeflerini çalışma birimleriyle sprintlere ayırabilirsiniz.
  • TDD ve Çevik tanımı ile. Birim testleriniz teslim edilemeyen birimleri yönetecek ve böylece TDD Agile'dan daha hızlı dönecektir. Her ikisini de kullanırsanız, Çevik döngüleriniz bir veya daha fazla TDD döngüsü içerir (her birim test edilirse).
  • Anladığım kadarıyla: Kullanıcıya teslim edilebilir/anlamlı bir birim geliştiremeyerek Agile'ı başarısızlığa uğratırsınız. Ünite, ürünü hızlandırsa bile anlamlı olabilir. Peki Agile daha kolay bakım için yeniden düzenlemeyi nasıl açıklıyor? Buna cevap vermek için yeterince örtmedim.
  • Birim sınamasından başarısız olarak TDD'yi başarısız olursunuz. Özelliği doğru üretmeyen kod üretmek.
1
Lee Louviere

Agile sizi her yinelemede program ve kalite risklerini ele almaya ve azaltmaya zorlar. yani TDD'nin Çevik olarak kabul edilmesine gerek yoktur.

Bununla birlikte, TDD, özellikle çok sayıda yinelemeye veya insana sahip bir proje için kalite risklerini azaltmak için muazzam bir tekniktir. Böyle bir projede, TDD erken yinelemelerde bazı program riski ekleyecektir, çünkü test senaryoları da yazmanız gerekir. Bununla birlikte, TDD, kalite risklerini sürekli olarak azalttığı için sonraki yinelemelerde büyük maliyet tasarrufu sağlar. yani TDD önerilir.

0
Jay Godse