Birim testleri olmadan çevik

Çalıştığınız kod tabanı% 0 birim test kapsamı içeriyorsa "çevik gelişim" hakkında konuşmak veya "çevik bir metodoloji" uyguladığınızı iddia etmek mantıklı mı? (Ve takım olarak, hiçbir şey yapmıyorsunuz).

Bunu açıklığa kavuşturmak için: bana göre, mantıklı değil. Kişisel tecrübeme göre, birim testlerinin gerçekten "çevik" olmanıza izin veren tek araç olduğunu (yani değişikliklere cevap vermenizi, tasarımınızı geliştirmeyi, bilginizi paylaşmayı vb.) Buldum ve TDD sizi oraya götüren tek uygulamadır .

Belki başka yollar da vardır, ama nasıl çalıştıklarını hala göremiyorum.

Bilgi niteliğinde olmak için, Çevik Manifesto veya Scrum Kılavuzundaki hiçbir şey, ünite testi veya TDD gibi teknik uygulamalara atıfta bulunmaz. Bu yüzden, evet, teoride onlarsız işbirliği ve değere odaklanarak erken ve sıklıkla teslim edebilir ve kendinizi Çevik olarak adlandırabilir, hatta çevikliğe bile sahip olabilirsiniz .

Bununla birlikte pratikte, iyi bir test paketi olmadan birkaç haftada bir sürekli olarak ( üretimde ) değer sunmak neredeyse imkansızdır . Bu, entegrasyon testlerinin yanı sıra birim testlerini de içerir. Ünite testleri sadece şimdiye kadar gidiyor. Piramit olmasının bir nedeni ve sonuçta dikdörtgen değil.

Bir güvenlik ağı olarak yapılan testler olmadan, her sürümde çok sayıda regresyon hatası ortaya çıkarır veya yeniden düzenlemekten korkarsınız. Her ikisi de sürdürülebilir bir hızla devam etme yeteneğinizi büyük ölçüde etkileyecektir . İhtiyacınız olduğunda hızınızı koruyamıyorsanız veya rotanızı değiştiremiyorsanız (yeniden tasarlayın), o zaman çevikliğe sahip değilsiniz. Sonuçta çeviklik, çabaladığımız hedef.

Çevik manifesto basitçe şöyle ifade eder:

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

Kapsamlı dokümantasyon üzerinde çalışan yazılım

Sözleşme müzakere konusunda müşteri işbirliği

Bir planı takip ederek değişime cevap vermek

Orada birim testlerinden söz edilmez. Hatta 12 prensipler test söz etmeyin.

Böylece teknik olarak, birim testleri yazmadan çevik bir ekip olabilir. Yine de pratikte, bir ekibin düzenli bir değişiklik yapmalarına yardımcı olmak için testler yapmadan çevik bir ortamda çalışma yazılımını nasıl sürdürdüğünü görmek gerçekten zor.

Ünite testi veya TDD veya başkalarının burada cevap verdiği gibi çevik manifestoda herhangi bir test hakkında doğrudan bir söz bulunmasa da, iyi bir Scrum Master veya Geliştiricisinin manifestodaki ifadelerden birini ayırt edebileceğine inanıyorum.

 Kapsamlı dokümantasyon üzerinden çalışan yazılım .

Yazılımın çalışıp çalışmadığını nasıl bilebilirim? Manifesto, test terimini açıkça belirtmek zorunda değildir. Bu özlü.

Ünite testi (konunun bağlamında) kodlama aşamasını daha erken aşamada yavaşlatır, ancak ilerledikçe buna değer olarak gelişir ve gelişimi daha hızlı hale getirir. Kod düzeyini test etmenin yanı sıra tasarımınızı ölçeklendirilebilir yapmanın yanı sıra, yazılımınızın çalıştığına ve regresyonu kolayca idare edebildiğine dair güven vermenizi sağlar; bu sizin gelişiminizi çevik kılacaktır.

Kesinlikle mantıklı. Çevik, başkalarının daha önce de belirtildiği gibi testlerle ilgili değil, sorunuzu özellikle yanıtlamak için:

Hayır, birim testine hiç ihtiyacınız yok.

Çevik bir işlemi yalnızca entegrasyon testi ile çalıştırabilirsiniz. Örneğin otomatik olarak bir entegrasyon testi yapabilir ve ertesi gün bulunan hataları düzeltebilirsiniz. İsterseniz sürekli olarak entegrasyon testlerini çalıştıran bir manuel test cihazına sahip olabilirsiniz. Sistemden bağımsız olarak ünite testi tamamen isteğe bağlıdır.

Birim testini geliştirmenize yardımcı olacak ve bunun için yeterince adil bulabilirsiniz, ancak geliştirmenize sahip olamayacağınız birçok şey var.

Eski “müşteri beta test cihazları” olsa bile bazı testlere ihtiyacınız var. Eğer müşteriniz sürece yoğun bir şekilde dahil olmuşsa ve hataları bulmaktan çekinmiyorsa, o zaman bu işe yarayabilir - başka kimsenin bile böcek olmadığını düşündüğü hataları bulma eğilimindedirler!

Bu gerekli değil. Test, gerçekten nasıl kullanılacağını bilen insanlar varsa harika. İstemediğinizde, sadece gerekli değil, aynı zamanda bir sorumluluk haline gelir. Çok yetenekli olmayan birçok programcı olduğunu söyleyebilirim.

Sorunuzda, çevik olmanın bazı metodolojileri izlemek yerine yazılımı nasıl serbest bırakacağınızla ilgili olduğunu kabul ettiğinize sevindim. Çevik Manifesto güzel bir referans ama kesin bir rehber değil. Çevik ondan önce vardı. "Daha çevik" olmak için yazılım geliştirmenin yolları var, ancak çeşitli projelerde farklı kombinasyonlar kullanılabilir.

Yeni yazılımı müşterinin kabul edebileceği bir hızda yayınlıyorsanız, muhtemelen çeviksiniz. Ayrıca çok fazla geri itme olmamasını ve geliştiricilerin özellik değişikliklerinden şikayet etmeyi de dahil ediyorum. Bir şeyi yalnızca diğerini kırmak için sabitlemek de ideal değildir. Kullanıcı olduğunuzda yükseltme sürümünün arkasında birkaç sürüm olduğunda, test edip etmemeniz muhtemelen çok çevik değildir.

Çevik manifesto'nun bu konuda açıkça bir şeyler söylediğini iddia etmek (diğer cevaplar) ile karşı karşıyayım:

Teknik mükemmellik ve iyi tasarımın sürekli ilgisi çevikliği arttırır.

LeSS'in teknik üstünlük tanımını gerçekten çok seviyorum ve birim testi ve TDD'yi içeriyor. Şimdi bunu başarmak için ünite testlerine veya TDD'ye ihtiyacınız olmayabileceğini iddia edebilirsiniz, ancak en yaygın ve muhtemelen tavsiye edilen yoldur.

Örgütsel Çeviklik, Teknik Çeviklik ile sınırlıdır

Başka bir deyişle, ürününüzde değişiklik yapmakta yavaş olduğunuzda, ekiplerinizi, organizasyonunuzu ya da hangi çerçeveyi benimsediğinizi benimsemeniz önemli değildir, değişikliklere cevap vermekte yavaş kalacaksınız.

Ürününüzün değişime başka bir şekilde direnmesini engelleyebilirseniz, doğru yolda olabilirsiniz, ancak:

Dünyayı programcılar için güvenli hale getirmek için Extreme Programming'i icat ettim. - Kent Beck

Scrum'da herhangi bir teknik uygulama bulunmuyor, ancak Jeff bu konuda şunları söyledi:

Extreme Programming geliştirme uygulamalarını kullanmayan, aşırı üretken bir Scrum ekibi görmedim. - Jeff Sutherland

Bu makaleden alıntı: http://ronjeffries.com/articles/017-02ff/gathering2017/

Teknik uygulamaları olmayan Scrum ekiplerinin de benzer şekilde uygulamalarını içeren retrospektifleri kullanarak beklemelerini beklerdim. Siz de hiper üretken olmak istersiniz, değil mi?

Çevik fluence modeli, iki yıldız düzeyinde eserinde bahsetmiştir:

Yararlı teknikler arasında sürekli entegrasyon, test odaklı geliştirme , çift programlama ve ortak sahiplik sayılabilir .

Yalnızca ilk Çevik akıcılık seviyesini hedeflerseniz, uygulamayı atlayabilirsiniz, ancak daha büyük ve daha uzun süre çalışan herhangi bir ürün en az iki yıldız seviyesine ulaşmaya çalışmalıdır.

Bu yüzden genel fikir birliği, iyi bir birim testi, temiz kod ve refactor uygulamaları olmadan evet, şu anda gerçekten Çevik olmak mümkün değildir. Bu, gelecekte yeni teknik uygulamalar ortaya çıktıkça değişebilir.

Robert C. Martin, Martin Fowler veya Kent Beck gibi bazı manifestolardan bazılarına sorarsak cevabın ne olacağını düşünüyorsunuz? Belki de buna bağlı olduğunu söylerler, ancak genellikle yapmanız gereken şeydir.