Test odaklı gelişme kim yapar?

Son 4½ yıldır işletme alanında çalışıyorum ve genel olarak konuşursak, işletmelerin ilk test geliştirme tarzı için elverişli ortamlar olmadığını farkettim. Projeler genellikle sabit maliyetli, sabit zaman çizelgesi ve şelale tarzıdır. Herhangi bir ünite testi, eğer hiç yapılıyorsa, genellikle QA aşamasında ve başka bir ekip tarafından geliştirildikten sonra gelir.

Bir işletme için çalışmaya başlamadan önce birçok küçük ve orta ölçekli şirkete danışmıştım ve hiçbiri ilk deneme tarzı bir geliştirme projesi için para ödemeye istekli değildi. Genellikle derhal veya kısa bir tasarım ipucudan sonra gelişimin başlamasını istediler: yani, bazı müşteriler her şeyin şelaleye benzer şekilde eşlenmesini istemesine rağmen, Çevik'e daha çok benzeyen bir şey.

Test odaklı geliştirme en iyi ne tür dükkan, şirket ve müşterilerle çalışıyor? TDD'ye ne tür projeler uygulanabilir?

Yazdığım her kod satırı test odaklı geliştirme kullanıyor. Eğer yönetim ilk önce yazılı testlerle kurulmazsa, o zaman yönetime söylemem. Test odaklı gelişimin daha iyi bir süreç olduğunu kuvvetle hissediyorum.

Patronum bugün benden iyi bir tane besledi, sanırım onu ​​başka birinden çalıyormuş gibi çalacağım.

“Bir marangozun levhayı kesmeden önce ölçmesini bekler miydiniz?”

Lisede ahşap atölyesi dersi aldım ve okulda inşaat yaptım. Mantramız her zaman "iki kere ölç, bir kere kes" oldu, bu alaycı tarafından takip edildi "Onu kesip tekrar kestim ve hala çok kısaydı!"

Sonra test yaparsanız, yazdığınız kodun test edilmesi zor olacağından, yeniden işleme oluşturursunuz. İlk test ettiğinizde, hatta ortada bir bit-biraz-bit-test etmeden önce, oluşturduğunuz yazılımı test etmeniz daha kolay olacaktır. Bir kontrol listesini karşılamak için üretim kodu yazıldıktan sonra birim testleri oluşturan bir işletme, boşa harcıyor.

Mevcut zor test yazılımı ile entegrasyon ayrıca ek çaba gösterecektir, zira parlak yeni test sürüşünüzün harcadığı bağımlılıkları kontrol edebilmek için test dikişleri oluşturmanız gerekecektir. Bazı durumlarda, örneğin, küresel devletten ve tanrı nesnelerinden ağır yararlanan çerçevelerle, bunu başarmak çok zor olabilir. Teste dayalı geliştirme sürecinin algılanan zorlukları genellikle iyi testler yazma ve sıkı bir şekilde bağlanmış kodları test etme konusundaki deneyimsizliğin bir birleşimidir.

Sürücü kodunu bir şelale projesinde bile test edebilirsiniz, bir proje yönetimi tekniği değil bir mühendislik disiplinidir.

Hiçbir şekilde TDD fanatiği değilim, ama yazılım tasarımı hakkında size çok şey öğretiyor.

Ayırt edici, net bir şekilde sahip olacağı gibi benimle ayı.

Test-ilk yaklaşımına uygun proje türleriyle ilgili olarak, dikkat edeceğim bazı şeyler:

• mevcut bir kod tabanıyla mı uğraşıyorsunuz? Bir test odasının yenilenmesi çok daha pahalıdır. Orada ne kadar kalıtsal teknik borcun olduğu hakkında bir fikir edinin.
• bazı platformlar ve çerçeveler doğası gereği test-dost değildir. Aklıma gelen son deneyim - örneğin SharePoint, TDD için çok zor (ancak imkansız değil). Bunun gibi şeyler için, TypeMock'un yardım edebileceği gibi ticari bir izolatör ürününe başvurmanız gerekebilir.
• Bazı uygulama yaklaşımları TDD'ye kendilerini diğerlerinden daha iyi borç veriyor. Örneğin, ASP-Kod kodları ile - test edilemez. ASP.Net MVC - test edilebilir. Kod tutucularla Silverlight - test edilebilir değil. MVVM ile Silverlight - test edilebilir.

Sonuçta, "organizasyon" test-birinci hareketini desteklemek için çok şey yapabilirken, yapılması gereken kilit değişiklik geliştiricilerin kafasındadır. "Önce kendi testlerini yazacaksın" yaklaşımından vazgeçtim, bunun yerine öğretilebilir anları aradım.

Mpenrow'un yorumunda, onunla bir sorunu varsa, mgmt'ye söylemediği hakkında yorum yapın: p

Durumunuz hızlı bir şekilde değişmeyecek ve başa çıkmanın anahtarı, kişisel disiplininizin bir parçası haline getirmek ve başkalarını zorlamaya çalışmadan önce bu konuda iyi olmak. Çalışmanın bir örneği olabilirseniz, yöneticileriniz objektif faydaları görmelidir.

Ayrıca iyi iş vakaları yapabilirsiniz:

• TDD, "sistemin kendini otomatik olarak doğrulayabildiği özellik" olarak özetlenebilir. Farklı programlama yapmaz, farklı bir ürün oluşturmaz.

• Birim testi gerçekten sadece otomatik bir test biçimidir; bu da sadece şirketin kendisi için et alanı mühendislerine el ile yapması muhtemel olan bedeli ödeyeceği şeyi yapmasına izin veriyor. Otomatikleştirilmiş testler daha hızlı, daha tutarlı çalışır ve - iyi yazıldığında - sorun için hızlı, özlü ve doğru geribildirim ve açıklamalar ile yön sağlar

• TDD, ne yaptıklarını bilen biri tarafından yapıldığında, sonuçları ilk kod kadar hızlı üretiyor. Bir öğrenme / eğitim eğrisi olacak (ve eğer mühendisleriniz yetenek havuzunun kısa ucundan geliyorsa, bu durum TDD'yi itme şansınızı tamamen ortadan kaldırabilir - bu durumda yapabileceğiniz en iyi şey onu savunmaya devam etmektir. ve makyaj yönetim soru onları yerine TDD yerine)

• TDD başlamadan önce eldeki görevi düşünmeyi çok istiyor. “İki kez ölç, bir kez kes” satırları boyunca - ekstra ölçüm göreve marjinal bir süre ekler, ancak en değerli kaynağınızı atmaktan kaçınır - dev saatler).

... ve sadece hatırla; Yapabileceğiniz en önemli şey örnek teşkil etmektir. TDD'ye kaba davranıyorsanız, daha iyi hale gelmek için fazladan birkaç saat yatırım yapın. Yeterli olduğunuzda, işte yapmaya başlamanız yeterli (yöneticileriniz gerçekten testler yazdığınızdan şikayet eder mi?). Her seferinde bir savaşta savaşın ve ona doğru adımlar atın - bütün Shebang'a gitmek muhtemelen başarısızlıkla sonuçlanacak ve zorla itilirseniz suçlama size düşecektir.

Ben yaparım. Bu benim tercih ettiğim gelişim tarzı ve son başvuru tarihlerine uygun ve kalite kodu ürettiğim sürece uygun göründüğü şekilde çalışmamdan memnun olan büyük bir finans şirketi için çalışıyorum. Doğru şekilde yapıldığında, testin ilk geliştirilmesinin geliştirmeden sonraki testten daha uzun sürmesi gerekmez ve daha sonra sistem testinden daha az hata çıkaran ilk test testinin diğer getirilerini de unutmayalım.

TDD yapmanın anahtarı, sadece kodunuzu yazmanın bir parçası olarak yapmaktır ve eğer gerekliyse, bunu yaptığınızı kimseye söylemiyorsunuz. Yaptığın her şeyi açıklamana gerek yok. Son sonucunuz çalışma kodudur.

"Testler yazıyorum" u açıklarsan, o zaman "Ah, bunu ortadan kaldırabiliriz!" Diyebilecek Güçler. Ama kimseye söylemezseniz, kodlama işleminin kalıntısı olarak testleriniz hala devam etmektedir.

Programlama, çalışma ifadelerini bir editöre yazmaktan daha fazlasıdır. Eğer insanlar bununla başa çıkamazsa, o zaman onları kullanmaya hazır olana kadar bu gerçeklerden koruyun. Bu durumda "Kullanmaya hazır", tamamlanmış bir projeniz olduğunda ya da iki kez sağlam, güvenilir kodla zamanında yapılan ve ah evet, bakın, bunun için de birim testleriniz olduğu anlamına gelir.

Söylemek üzücü, kendimi gerçekten klasik test-ilk anlamında kullanma şansım olmadı, bu yüzden "ben! Ben! Ben yaparım!" Diyemem. Sorunun, “TDD'yi günlük hayatlarına sokabilecek herhangi biri yerine“ hangi sektörleri / şirketleri TDD kullandığını ”sorduğu sorusunu sorduğunu farz ediyorum. Bireysel bir geliştiricinin tüm grubu yapmaya zorlamadan TDD'yi tamamen yapabileceği konusunda hemfikirim, sadece sorunun bu olduğunu sanmıyorum.

Endüstride dinlemekten duyduğum izlenim, aşağıdaki durumlarda bir şirketteki çoğu geliştirme grubunda TDD'yi görme olasılığınızın daha yüksek olduğu:

• TDD'nin kurulmasından önce büyük bir kod tabanı yoktur.

• Şirket muazzam değildir ve bu nedenle “her zaman başka bir yoldan yaptık” itirazına sahip değildir.

• Şirket, resmileştirilmiş süreç için devasa bir satın alma işlemine sahip değil. Bu, örneğin bir CMMI sertifikalı şirkette TDD'yi uygulayamayacağınız anlamına gelmez - ancak TDD olmayan bir süreciniz varsa, CMMI ile izlemekte olduğunuz tüm işlemleri güncellemek büyük bir yatırım olabilir.

• Testler kodlanabilir - bu en karmaşık kod tabanlarıdır, çünkü kullanıcıya en yakın katmanı kolayca kodlayamasanız bile, iç kısımlardan bazılarını kodlayabilirsiniz. Ancak, test otomasyonu için iyi gelişmiş seçeneklere sahip durumları TDD'nin en tatlı noktaları olarak görüyorum, çünkü çok hızlı bir şekilde test etme konusunda geribildirim almanız gereken bütün bir test bataryasını yeniden denemek ve kırmamak üzerine kuruludur. Benim düşüncem, bağımsız bir web uygulamasının iyi bir TDD hedefi olduğu, büyük COTS entegrasyonuna sahip bir sistem veya GUI tabanlı olmayan girdilerin zor olabileceğidir.

• Prototipsiz bir durumda sistemler. İdeal bir sonraki büyük versiyonu sonra prototip - kavram ispatı tamamlanmış olup proje finanse edilmektedir, ama herkes bir sonraki girişimi kalitesinde atlamak zorunda olduğunu bilir nerede.

• Sürece yatırım yapan paydaşlar.

Mümkün olan her şeyi denedim - ama bence kendinizi bulduğunuz kurumsal ortama bağlı. Uzun yıllar oyun endüstrisinde çalıştım (btw sanatçısı olarak) ve TDD kavramı yoktu - sadece kaba kuvvet QA yaklaşımı. Web geliştirmeye geçtim ve henüz herhangi bir resmi tanıma (veya ... bilgisi) birim test / TDD'si olan bir ajansta çalışmak zorunda kalmadım. Aynı şey, çok çeşitli disiplinlerde çalışan sektördeki meslektaşlarım için de geçerlidir.

Satış odaklı bir ajansta, TDD müşteriye çok az kısa vadeli yatırım getirisi sunuyor ve bu nedenle bir projeyi belirlerken hat yöneticilerine satış yapmak zor. Bir proje büyüdükçe, daha da ikna edici oluyor.

Ölüm Mart gibi kitapların yaygın bir olguya, yani “çıtırtı” ve “dönüm noktası” güdümlü bir gelişime maruz kaldığı bir sektöre işaret ettiği göz önüne alındığında, TDD'nin iyi finanse edilen başlangıçlar veya monolitik işletme dükkanları dışında nadiren bulunduğunu iddia ediyorum. Buradaki insanlar TDD'nin değerine inanmıyorlar - ama müşterilerine satmak için fazla soyut.

TDD'ye kendim girmeye çalışıyorum. Bence zaten bildiğiniz güzergahları takip ettiğiniz sürece (günlük iş) oldukça basit. Ancak kafamı UI parçaları için yapılan testler etrafına ya da daha önce karşılaşmamış olduğunuz bazı sorunlara yeni bir çözüm bulmak zorunda kalacağım. Veya bilmediğiniz bir çerçeve kullanarak.

Bu yüzden, bir tür LearningTest yapmak zorundasınız, ayrı kavram kanıtları ve sonradan yeniden yazmanız vs.

Ve (eski olduğunu biliyorum ama henüz iyi bir cevap görmedim): TDD'yi kullanarak algoritmaları nasıl kodlarsınız (sonuçlar gerçekten "İddia" ile karmaşıklaşmak olabilirken)?

Teknede TDD ve im'in olumlu yanlarını gerçekten görebiliyorum ancak yazdığınız kod sizi en fazla iki katına çıkardığında yeni başlayanlar için çok zor (ve artıları hiç görmeyen ve sizi alay eden arkadaşlarınız var. RAD ile)

Birkaç kez denedim ve harika çalıştı. Ne yazık ki çoğu zaman uygulamamı manuel olarak test edebilirsem, başka bir şeyi uygulayamayacak kadar sıkıldım ya da kolayca çözemediğim bir hata olana kadar ünite testlerini ertelerim.

Yaptım. Kullanıcı hikayelerimizin ilerlemesi, "Testi Var mı?" Olan bir Kanban panosunda izlenir. Kalkınmanın solundaki sütun (yukarı akış).

Bu alışılmadık bir düzen, bir politikanın açık olmasını sağlar: başarısız bir otomatik kabul testi (genellikle bunlardan birkaçı) mevcut olmalıdır. Bir müşteri ihtiyacına göre izlenebilir olmalıdır. Kabul testleri , hikaye kartıyla başlayan konuşmalardan kaynaklanan memnuniyet koşullarından kaynaklanmaktadır . Gereksinim içinde beyin fırtınası yaptığımız, boşlukları belirlediğimiz ve kullanıcı değerinin geçerken verilmesini sağlayan anahtar kabul testlerini yaptığımız düzenli atölye çalışmalarını kolaylaştırıyorum (yapılan tanım ). Programcıları, iş analistlerini ve bazen de test uzmanlarını içeren ortak bir etkinliktir.

Kabul testi geri bildirim döngüsü uzun sürüyor: hikayeyi tamamlamak birkaç gün sürebilir. Gelişimin kendine ait daha kısa TDD geri bildirim döngüleri var.

“[... hiçbir test-ilk tarzı yok ...]

Bu, Çevik'in eksiksiz bir yanlış beyanıdır. Yapılanın tanımı Agile'nin kilit bir bileşenidir ve dayandığı dayanaklardan biri otomatik kabul testidir (yukarıda tanımladığım şey bunu yapmanın bir yoludur.) Eğer aşırı programlama (XP) bir Çevik uygulama yöntemi olarak kullanılıyorsa, o zaman ATDD / BDD ve TDD reçete edilir.

Yaparım, ancak genel olarak sadece kullanıcı arayüzü olmayan bileşenler için ve bildiğimde kafamdaki bir modül için tüm algoritmayı tek bir anda tutamayacağımı veya modül üzerinde çalıştığım sistemin ne olursa olsun yeni bir parçası olduğu zaman, bu yüzden yüksek oranda hata ayıklamak için kullandığım kütüphanelerin çoğuna güvenemiyorum.

Temel olarak, ihtiyacın karmaşıklığının kodda aksi halde kaybolacağım anlamına geldiğini yapıyorum.

Başlamak zor bir alışkanlıktır ve yönetim satın almayı gerektirir, ancak testleriniz gelişimden yarı yarıya ayrılmaya başladığında hayat kurtarıcı olabilir!

Bu soruyu sormak istedim, kaç tane şirketin TDD'yi uyguladığını görmek istedim.

Profesyonelce programlama yaptığım 11 yılda, yalnızca son iki kuruluş TDD'nin bile farkındaydı (bu, neredeyse 5 yılını kapsıyordu, bundan önce TDD bugün olduğu kadar popüler değildi). TDD için satış adımına geçmeden önce takip etmeye devam edeceğim ve sorunuzu cevaplayacağım :)

En son çalıştığım şirkette (beşeri bilimler ve bilim koleksiyonlarının çevrimiçi akademik yayıncısı), TDD'yi uygulamak için ihtiyacımız olduğunu biliyorduk ama oraya asla ulaşamadık. Savunmamızda bir 250k kod tabanımız vardı, bu yüzden test edilemeyen bir kod tabanına testler eklemek aşılmaz hissettiriyordu (şimdi bunu yazarak suçlu hissediyorum!). En iyilerimiz bile hata yapar .

Küçük bir miktar TDD bile yapanlar, test edilemeyen kahverengi tarlalara ne kadar acı verici güçlendirme testlerinin uygulanabileceğini bilir ... Başlıca nedenler dolaylı bağımlılıklardır (tüm kolları koddan iddia etmek için çekemezsiniz - alay edemezsiniz) senaryolar) ve tek sorumluluk ilkesinin ihlali (testler karmaşık, karmaşık, çok fazla kurulum gerektiriyor ve anlaşılması zor ).

QA ekibimizi (bir, belki iki kişiden yarım düzine veya daha fazla) herhangi bir sürümden önce platformu test etmek için geçici olarak büyüttük . Akıllıca ve mali açıdan oldukça pahalı bir zamandı, bazı sürümlerin 'testi' tamamlaması üç ay alacaktı. O zaman bile sorunla karşı karşıya olduğumuzu biliyorduk, sadece 'engelleyici' ya da 'kritik' değil, sadece 'yüksek öncelikli'.

Yıllar süren bir ticari deneyiminiz varsa, her şirketin kritik görevler üstlendiğini takdir edersiniz ve daha sonra bunun üzerinde daha yüksek bir öncelik seviyesi yaratır ve büyük olasılıkla bunun da üzerinde - özellikle yukarıdan bir kişi bir özellik / hata düzeltmesi bastırdığında. Dalıyorum ...

Şu anki şirketimde (telekomünikasyon, web ve mobil uygulama geliştirme evi) TDD uyguladığımı ve diğer statik analiz raporlarını vermek için Jenkins testiyle (test paketi geçtikten sonra en kullanışlı olan kod kapsamı) bildirdiğime sevindim. . TDD'yi kullandığım projeler bir ödeme sistemi ve şebeke hesaplama sistemidir.

Satış perdesi ...

Teknik olmayan ekip üyelerine otomatik test yapılmasını haklı çıkarmak sık sık sıkıntı verici bir mücadele olabilir. Testler yazmak geliştirme sürecine daha fazla iş ekler, ancak ... şimdi test etmeye yatırım yaptığınız zaman, daha sonra bakım çabasından tasarruf edersiniz. Gerçekten sadece ödünç zaman alıyorsun . Ürün ne kadar uzun süre kullanılırsa, o kadar fazla tasarruf edersiniz - ve yeniden yazmaktan kaçınmanıza yardımcı olur .

Önce sınama, önce amacınızı kodladığınız ve ardından kodunuzun bu amacı yerine getirdiğini onayladığınız anlamına gelir. Bu, odaklanma sağlar ve kodunuzu yalnızca amaçlananı yapmaktan başka bir şey yapmamak için dağıtır. Aynı zamanda çalıştırılabilir bir özellik ve dokümantasyondur (aynı zamanda testiniz iyi yazılmışsa ve testler sistem kodunuz kadar okunabilir / temiz olmalıdır, daha fazla değilse!).

Programcı olmayanlar (çoğu zaman) bu kavrayışa sahip olmayacaklar ve TDD onlar için fazla bir değere sahip değil ve daha önceki bir sürüm tarihine atılabilir bir kısayol olarak görülüyor.

Programlama bizim alanımızdır ve bence TDD gibi en iyi uygulamalarla ilgili olarak profesyonel olarak danışman olarak bizim sorumluluğumuzdadır . Proje yöneticilerinin gelişim süresini kısaltmak için yapılıp yapılmadığına karar vermeleri için kendi yetki alanları dışındadır . Aynı şekilde, hangi çerçeveyi, önbelleğe alma çözümünü veya arama algoritmasını kullanmanız gerektiğini size söylemezler, otomatik sınama kullanıp kullanmamanız gerektiğini size söylememeliler.

Gelen Bence yazılım geliştirme endüstrisi (bütün üzerine), şu anda yazılımınızın testleri sahip norm DEĞİL olduğu gerçeğini bozuldu.

Bunu diğer endüstrilerde hayal edin: tıp, havacılık, otomobil, kozmetik, yumuşak oyuncaklar, alkollü içecekler vb.

Belki de hiçbir testin yapıldığını söylemek haksızlıktır ... çünkü otomatik test yapılmayan şirketlerde, çok manuel / insan (tıknaz ve sık sık hataya açık) işlemi okuyor.

Sorunuzda tartışacağım bir nokta ...

Genellikle gelişimin hemen veya kısa bir tasarımın ardından başlanmasını istediler. Agile'ye daha çok benziyor.

"Çevik" olmak, testler olmadan devam etmeyi öngörmez , agilemanifesto.org'da listelenen ilk üye , XP ve TDD'nin yaratıcısı Kent Beck'dir !

TDD ile ilgileniyorsanız, ya da sadece okumadıysanız ve keskin bir programcıysanız, iki kitap tavsiye ederim (herkes bu hakkı okuyor mu?;)

Testlerin Rehberliğinde Büyüyen Nesneye Dayalı Yazılım

Temiz Kod - Robert C Martin ("Bob Amca") Serisi

Bu iki kitap birbirine iltifat eder ve birkaç sayfaya yoğun bir şekilde bakmaktadır.

Bu soruyu sorduğun için teşekkürler :)

Klonları uygulayanlar. Mevcut bir program gibi çalışan bir şey geliştirirken daha iyi bir süreç düşünemiyorum.

Açıkçası bu oldukça sıradışı bir durum, ancak SQLite geliştiricileri yoğun bir şekilde test ediyor. (Geliştirme süreçlerinin ilk test olduğunu sanıyorum, ancak emin değilim.)

• 73.000 kod satırı
• 91,378,600 test kodu satırı

Bkz http://www.sqlite.org/testing.html