Tam bir kapsam elde etmek için ekibi TDD'ye dönüştürdükten sonra olası tüm test senaryolarını yazmak iyi bir fikir mi?

Herhangi bir birim / fonksiyonel test olmaksızın kurumsal düzeyde büyük bir uygulamamız olduğunu varsayın. Geliştirme sırasında çok sıkı son teslim tarihleri ​​nedeniyle test odaklı bir geliştirme süreci yoktu (emin olmadığımızda asla kesin son teslim tarihlerine söz vermememiz gerektiğini biliyorum, ama ne yapılıyor!)

Artık tüm teslim tarihleri ​​geçti ve işler sakinleşti, herkes bizi verimli bir TDD / BDD tabanlı ekibe dönüştürmeyi kabul etti ... Yay!

Şimdi soru zaten sahip olduğumuz kodla ilgili: (1) Her şey tamamen çalışıyor olsa bile, gelişimin çoğunu durdurmak ve tüm olası test senaryolarını baştan yazmaya başlamak hala iyi mi yoksa iyi bir fikir mi? ? Veya (2) kötü bir şey olmasını beklemek daha iyidir ve daha sonra düzeltme sırasında yeni birim testleri yazın veya (3) önceki kodları unutun ve sadece yeni kodlar için birim testleri yazın ve her şeyi bir sonraki büyük refactor'a erteleyin.

Birkaç iyi ve bu şekilde ilgili makaleler bulunmaktadır bu bir . Çok sınırlı bir zamanımız olduğu ve diğer birçok projenin / çalışmanın bizi beklediğini düşünerek buna yatırım yapmaya değer olup olmadığından hala emin değilim.

Not : Bu soru bir geliştirme ekibindeki tamamen garip bir durumu açıklıyor / hayal ediyor. Bu benim veya meslektaşlarımın hiçbiriyle ilgili değil; bu sadece hayali bir durum. Bunun asla olmaması gerektiğini veya geliştirme müdürünün böyle bir karmaşadan sorumlu olduğunu düşünebilirsiniz! Ama her neyse, yapılanlar yapılır. Mümkünse, lütfen bunun asla gerçekleşmeyeceğini düşündüğünüz için indirmeyin.

Çok sıkı son teslim tarihleri ​​nedeniyle geliştirme sırasında test odaklı bir geliştirme süreci yoktu

Bu ifade çok endişe vericidir. TDD olmadan geliştirdiğiniz veya her şeyi test etmediğiniz için değil. Bu endişe verici çünkü TDD'nin sizi yavaşlatacağını ve bir son tarihi kaçırmanıza neden olacağını gösteriyor.

Bu şekilde gördüğünüz sürece TDD için hazır değilsiniz. TDD yavaş yavaş rahatlayabileceğiniz bir şey değildir. Bunu nasıl yapacağınızı biliyorsunuz ya da bilmiyorsunuz. Bunu yarıya kadar denerseniz, kendiniz kötü görüneceksiniz.

TDD ilk önce evde pratik yapmanız gereken bir şeydir. Eğer yardımı çünkü bunu yapmak için öğrenin size kod şimdi . Birisi sana bunu yapmanı söylediğinden değil. Daha sonra değişiklik yaptığınızda yardımcı olacağı için değil. Yapılan bir şey olduğunda , çünkü sen Aceleniz sonra profesyonel olarak yapmaya hazırız.

TDD, herhangi bir dükkanda yapabileceğiniz bir şeydir . Test kodunuzu çevirmeniz bile gerekmez. Diğerleri testleri reddederse bunu kendinize saklayabilirsiniz. Doğru yaptığınızda, testler başka hiç kimse çalıştırmasa bile gelişiminizi hızlandırır.

Öte yandan, başkaları testlerinizi seviyor ve çalıştırıyorsa, bir TDD mağazasında bile testleri kontrol etmek sizin işiniz değildir. Kanıtlanmış çalışan üretim kodu oluşturmaktır. Eğer test edilebilir olursa, temiz.

Yönetimin TDD'ye inanması veya diğer kodlayıcılarınızın testlerinizi desteklemesi gerektiğini düşünüyorsanız, TDD'nin sizin için en iyi şeyi görmezden geliyorsunuz. Kodunuzun yaptığını düşündüğünüz ile gerçekte ne yaptığı arasındaki farkı hızlı bir şekilde gösterir.

Eğer kendi başına, son teslim tarihini daha hızlı karşılamanıza nasıl yardımcı olabileceğini göremiyorsanız işte TDD için hazır değilsiniz. Evde pratik yapmalısın.

Bununla birlikte, ekibin üretim kodunuzu okumalarına yardımcı olmak için testlerinizi kullanması ve yönetimin yeni TDD araçları satın alması hoş olur.

Ekibi TDD'ye dönüştürdükten sonra olası tüm test senaryolarını yazmak iyi bir fikir mi?

Ekibin ne yaptığından bağımsız olarak, olası tüm test senaryolarını yazmak her zaman iyi bir fikir değildir. En kullanışlı test senaryolarını yazın. % 100 kod kapsamı bir maliyete sahiptir. Yargılama çağrısı yapmak zor olduğu için geri dönüşlerin azaltılması yasasını göz ardı etmeyin.

İlginç iş mantığı için test enerjinizi koruyun. Kararlar veren ve politikayı uygulayan şeyler. Heck bunu test et. Sadece bir şeyleri birbirine bağlayan, okunması kolay bariz yapısal yapıştırıcı kodunun sıkıcı olması, neredeyse kötü bir şekilde teste ihtiyaç duymaz.

(1) Her şey tamamen iyi çalışsa bile, gelişimin çoğunu durdurmak ve mümkün olan tüm test senaryolarını baştan yazmaya başlamak hala iyi veya iyi bir fikir mi? Veya

Hayır. Bu "tamamen yeniden yazalım" düşüncesidir. Bu zor kazanılmış bilgiyi yok eder. Yönetimden test yazması için zaman istemeyin. Sadece testler yaz. Ne yaptığınızı öğrendikten sonra, testler sizi yavaşlatmaz.

(2) kötü bir şey olmasını beklemek daha iyidir ve daha sonra düzeltme sırasında yeni birim testleri yazın veya

(3) önceki kodları bile unutun ve sadece yeni kodlar için birim testleri yazın ve her şeyi bir sonraki büyük refactor'a erteleyin.

2 ve 3'e aynı şekilde cevap vereceğim. Kodu değiştirdiğinizde, herhangi bir nedenle, bir teste geçebiliyorsanız gerçekten güzel. Kod eskiyse, şu anda bir testi kabul etmemektedir. Bu, değiştirmeden önce test etmek zor olduğu anlamına gelir. Yine de değiştirdiğiniz için test edilebilir bir şeye dönüştürebilir ve test edebilirsiniz.

Bu nükleer seçenek. Riskli. Testler olmadan değişiklik yapıyorsunuz. Eski kodu değiştirmeden önce test etmek için bazı yaratıcı hileler vardır. Kod değiştirmeden kodunuzun davranışını değiştirmenize izin veren dikişler olarak adlandırılan şeyi ararsınız. Yapılandırma dosyalarını değiştirir, dosyaları oluşturur, ne olursa olsun.

Michael Feathers bize bu konuda bir kitap verdi: Eski Kod ile Etkili Çalışma . Bir okuma yapın ve yeni bir şey yapmak için eski her şeyi yakmanız gerekmediğini göreceksiniz.

Gelişimin çoğunu durdurmak ve baştan başlayarak tüm olası test senaryolarını yazmaya başlamak iyi ya da iyi bir fikir mi?

Eski ¹ kodu verildiğinde , aşağıdaki durumlarda birim testleri yazın:

• hataları giderirken
• yeniden düzenleme yaparken
• mevcut koda yeni işlevler eklerken

Birim testleri kadar kullanışlı, mevcut ¹ kod tabanı için eksiksiz bir birim test paketi oluşturmak muhtemelen gerçekçi bir fikir değildir. Sizi sıkı bir teslim tarihine iten güçler. Geliştirirken yeterli birim testleri oluşturmanıza zaman tanımadılar. Sizce "çalışan program" için testler hazırlamanız için yeterli zaman tanıyacaklar mı?

¹ _{Eski kod, birim testleri olmayan koddur. Bu, eski kodun TDD tanımıdır. Eski kod yeni dağıtılmış olsa bile geçerlidir (mürekkep henüz kurumamış olsa bile).}

Deneyimlerime göre, testlerin yardımcı olması için toplam kapsama ihtiyacı yoktur. Bunun yerine, kapsama alanı arttıkça farklı avantajlar elde etmeye başlarsınız:

• % 30'dan fazla kapsam (birkaç entegrasyon testi olarak da bilinir): testleriniz başarısız olursa, bir şey son derece bozulur (veya testleriniz kesintilidir). Neyse ki testler sizi hızlı bir şekilde uyardı! Ancak sürümler yine de kapsamlı manuel testler gerektirecektir.
• % 90'dan fazla kapsama alanı (diğer bir deyişle bileşenlerin çoğunda yüzeysel birim testleri vardır): testleriniz başarılı olursa, yazılım büyük olasılıkla iyidir. Test edilmemiş parçalar, kritik olmayan yazılımlar için iyi olan kenar kılıflarıdır. Ancak sürümler yine de bazı manuel testler gerektirecektir.
• çok yüksek fonksiyon / ifade / şube / gereksinim kapsamı: TDD / BDD rüyasını yaşıyorsunuz ve testleriniz yazılımınızın işlevselliğinin tam bir yansımasıdır. Büyük ölçekli mimari değişiklikler de dahil olmak üzere yüksek güvenle yeniden düzenleyebilirsiniz. Testler geçerse, yazılımınız neredeyse kullanıma hazırdır; sadece bazı manuel duman testleri gerekir.

Gerçek şu ki, BDD ile başlamazsanız oraya asla gitmeyeceksiniz, çünkü kodlamadan sonra test etmek için gereken iş çok fazla. Mesele testleri yazmak değil , daha çok fiili gereksinimlerin farkında olmak (tesadüfi uygulama detaylarından ziyade) ve yazılımı hem işlevsel hem de test edilmesi kolay bir şekilde tasarlayabilmektir . Testleri önce veya kodla birlikte yazdığınızda, bu pratik olarak ücretsizdir.

Yeni özellikler test gerektirdiğinden, testler tasarım değişiklikleri gerektirdiğinden, yeniden düzenleme de testler gerektirdiğinden, bir miktar tavuk ve yumurta probleminiz var. Yazılımınız iyi kapsama alanına yaklaştıkça, yeni özelliklerin test edilebilir olması için kodun yeni özelliklerin oluştuğu kısımlarında dikkatli bir şekilde yeniden düzenleme yapmanız gerekir. Bu başlangıçta sizi çok yavaşlatacaktır. Ancak, yalnızca yeni geliştirmenin gerekli olduğu parçaları yeniden düzenleyerek ve test ederek, testler aynı zamanda en çok ihtiyaç duydukları alana da odaklanır. Kararlı kod testler olmadan devam edebilir: buggy olsaydı, yine de değiştirmeniz gerekir.

TDD'ye uyum sağlamaya çalışırken, toplam proje kapsamından daha iyi bir metrik, değiştirilen kısımlardaki test kapsamı olacaktır. Bu kapsam, baştan itibaren çok yüksek olmalıdır, ancak kodun bir yeniden düzenleme işleminden etkilenen tüm bölümlerini test etmek mümkün değildir. Ayrıca, test edilen bileşenler içindeki yüksek test kapsamının faydalarının çoğunu elde edersiniz. Bu mükemmel değil, ama yine de oldukça iyi.

Birim testleri yaygın gibi görünse de, en küçük parçalardan başlayarak eski bir yazılımı teste almak için uygun bir strateji değildir. Yazılımın büyük bir kısmını aynı anda kullanan entegrasyon testleriyle başlamak isteyeceksiniz.

Örneğin, gerçek dünya günlük dosyalarından entegrasyon test senaryolarının çıkarılmasını yararlı buldum. Elbette bu tür testleri çalıştırmak çok zaman alabilir, bu yüzden testleri düzenli olarak çalıştıran otomatik bir sunucu kurmak isteyebilirsiniz (örneğin , taahhütler tarafından tetiklenen bir Jenkins sunucusu). Böyle bir sunucunun kurulum ve bakımının maliyeti, test hatalarının gerçekten hızlı bir şekilde düzeltilmesi şartıyla, düzenli olarak test yapılmamasına kıyasla çok düşüktür.

Mevcut kod için test yazmayın. Buna değmez.

Yaptığınız şey zaten tamamen gayri resmi bir şekilde test edildi - sürekli olarak denediniz, insanlar otomatikleştirilmemiş bazı testler yaptılar, şimdi kullanılıyor. Bu, çok fazla hata bulamayacağınız anlamına gelir .

Geriye ne düşündüğün hataları. Ama bunlar da her ikisi için de birim testleri yazmayı düşünmeyeceğiniz şeyler, bu yüzden muhtemelen onları hala bulamayacaksınız.

Ayrıca, TDD'nin bir nedeni, yazmadan önce biraz kodun tam gereksinimlerinin ne olduğunu düşünmenizi sağlamaktır. Ne olursa olsun, bunu zaten yaptın.

Bu arada, bu testleri yazmak daha önce yazmak gibi daha fazla iştir. Çok az fayda sağlamak için çok zamana mal olacak.

Ve aralarında kodlama ve neredeyse hiç hata bulamadan çok sayıda test yazmak son derece sıkıcıdır . Bunu yapmaya başlarsanız, TDD'de yeni olan insanlar bundan nefret edecektir.

Kısacası, devs bundan nefret edecek ve çok fazla hata bulunmasa da yöneticiler maliyetli olarak görecekler. Asıl TDD kısmına asla ulaşamayacaksınız.

Sürecin normal bir parçası olarak değiştirmek istediğiniz şeylerde kullanın.

Test, anlayışı iletmek için bir araçtır.

Bu nedenle sadece anladığınız şeyler için testler doğru olmalıdır.

Sadece onunla çalışırken neyin doğru olması gerektiğini anlayabilirsiniz.

Bu nedenle yalnızca birlikte çalıştığınız kod için testler yazın.

Kod ile çalıştığınızda öğreneceksiniz.

Bu nedenle öğrendiklerinizi yakalamak için testleri yazın ve yeniden yazın.

Durulayın ve tekrarlayın.

Testlerinizle birlikte bir kod kapsamı aracı çalıştırın ve ana hatta yalnızca kapsamı azaltmayan taahhütleri kabul edin. Sonunda yüksek bir kapsama alanına ulaşacaksınız.

Kodla bir süredir çalışmadıysanız, bir işletme kararı alınması gerekir. Artık takımınızdaki hiç kimse onunla nasıl çalışacağını bilmeyecek kadar eski. Muhtemelen güncel olmayan kütüphaneler / derleyiciler / dokümantasyona sahiptir ve bu hemen hemen her şekilde büyük bir sorumluluktur.

İki seçenek:

1. Okumak için zaman ayırın, ondan ders alın, testler yazın ve yeniden düzenleyin. Sık sürümlerle küçük değişiklik setleri.
2. Bu yazılımı atmanın bir yolunu bulun. Yine de istendiğinde muhtemelen bir değişiklik yapamazsınız.

(1) Her şey tamamen iyi çalışsa bile, gelişimin çoğunu durdurmak ve mümkün olan tüm test senaryolarını baştan yazmaya başlamak hala iyi veya iyi bir fikir mi?
(2) kötü bir şey olmasını beklemek daha iyidir ve daha sonra düzeltme sırasında yeni birim testleri yazın

Testlerin temel amaçlarından biri, bir değişikliğin hiçbir şeyi bozmadığından emin olmaktır. Bu üç aşamalı bir süreçtir:

1. Testlerin başarılı olduğunu onaylayın
2. Değişiklik yap
3. Testlerin hala başarılı olduğunu onaylayın

Bu, bir şeyi gerçekten değiştirmeden önce çalışma testlerine sahip olmanız gerektiği anlamına gelir . İkinci yolu seçerseniz, bu, geliştiricilerinizi koda dokunmadan önce test yazmaya zorlamak zorunda kalacağınız anlamına gelir. Şimdiden gerçek dünyadaki bir değişiklikle karşılaştıklarında, geliştiricilerin birim testlerine hak ettikleri dikkati vermeyeceğinden şüpheleniyorum.

Bu yüzden geliştiricilerin birinden diğeri için kaliteden ödün vermelerini önlemek için test yazma ve değişiklik yapma görevlerini bölmeyi öneriyorum.

her şey tamamen çalışıyor olsa bile (henüz!)?

Bunu özellikle belirtmek gerekirse, sadece kod çalışmadığında testlere ihtiyacınız olduğu yaygın bir yanlış anlamadır. Kod da çalışırken testlere ihtiyacınız var, örneğin [yeni ortaya çıkan hataların] sizin parçanızdan kaynaklanmadığını birisine kanıtlamak için testler hala geçiyor.
Her şeyin daha önce olduğu gibi çalıştığını onaylamak , kod çalışırken testlere ihtiyacınız olmadığını ima ettiğinizde atladığınız testin önemli bir yararıdır.

(3) önceki kodları bile unutun ve sadece yeni kodlar için birim testleri yazın ve her şeyi bir sonraki büyük refactor'a erteleyin

İdeal olarak, mevcut kaynak kodlarının tümü artık birim testleri almalıdır. Bununla birlikte, bunun için gereken zaman ve çabanın (ve maliyetin) belirli projeler için geçerli olmadığı konusunda makul bir argüman vardır.
Örneğin, artık geliştirilmeyen ve artık değiştirilmesi beklenmeyen uygulama (örneğin, istemci artık kullanmıyor veya istemci artık istemci değil), bu kodu test etmenin artık uygun olmadığını iddia edebilirsiniz. .

Ancak, çizgiyi çizdiğiniz yer net değildir. Bu, bir şirketin maliyet fayda analizinde bakması gereken bir şeydir. Test yazmak zaman ve çaba gerektirir, ancak bu uygulamada gelecekte herhangi bir gelişme bekliyorlar mı? Birim testlerinden elde edilen kazançlar, bunları yazma maliyetinden daha ağır mıdır?

Bu (geliştirici olarak) verebileceğiniz bir karar değildir. En iyi ihtimalle, belirli bir projeye test uygulamak için gereken süre için bir tahmin sunabilirsiniz ve projeyi gerçekten sürdürmek / geliştirmek için yeterli bir beklentinin olup olmadığına karar vermek yönetime bağlıdır.

ve her şeyi bir sonraki büyük refactor'a ertelemek

Bir sonraki büyük refactor verilmişse, gerçekten testleri yazmanız gerekir.

Ancak büyük değişikliklerle karşılaşana kadar bunu ertelemeyin. Başlangıç ​​noktam (testlerin yazılması ve kodun güncellenmesi değil) hala duruyor, ancak buraya ikinci bir nokta eklemek istiyorum: geliştiricileriniz şu anda proje etrafında yollarını altı ay içinde çalışarak geçirecekleri zamandan daha iyi biliyorlar diğer projelerde. Geliştiricilerin zaten ısındığı ve gelecekte işlerin nasıl tekrar çalıştığını anlamaya gerek duymadığı dönemlerden yararlanın.

Benim görüşüm:

Sisteme önemli bir teknik güncelleme yapılmasını bekleyin ve testleri yazın ... resmi olarak işin desteğiyle.

Alternatif olarak, bir SCRUM mağazası olduğunuzu, iş yükünüzün kapasite ile temsil edildiğini ve bunun% 1'ini birim testine ayırabilirsiniz, ancak ...

Geri dönüp testleri yazacağınızı söylemek naif, gerçekten yapacağınız testler, refactor yazmak ve refactor kodu daha test edilebilir hale getirdikten sonra daha fazla test yazmaktır, bu yüzden başlamak en iyisidir zaten bildiğiniz gibi testlerle ve ...

Orijinal yazarın daha önce yazdıkları kod için test yazması ve yeniden düzenleme yapması en iyisidir, ideal değildir, ancak deneyimlerden, refactor'un kodu daha da kötü değil daha iyi hale getirmesini istersiniz.