Mevcut bir üretim projesine ünite testi başarıyla eklenebilir mi? Eğer öyleyse, nasıl ve buna değer mi?

Üretimde olan mevcut bir projeye birim testi eklemeyi düşünüyorum. TDD'nin (yüz avuç içi) herhangi bir faydasını gerçekten görebilmem için 18 ay önce başladı , bu yüzden şimdi bir dizi projeyle oldukça büyük bir çözüm ve birim testleri eklemeye nereden başlayacağımı en ufak bir fikrim yok. Bunu bana düşündüren şey, bazen eski bir hatanın yeniden ortaya çıktığı ya da bir hatanın gerçekten düzeltilmeden sabit olarak teslim edildiğidir . Birim testi, bu sorunların ortaya çıkmasını azaltır veya önler.

SO ile ilgili benzer soruları okuyarak , hata izleyiciden başlamak ve her bir hata için gerilemeyi önlemek için bir test senaryosu yazmak gibi öneriler gördüm. Bununla birlikte, TDD'yi en başından itibaren kullansaydım, büyük resmi kaçırmam ve nihai temel testleri kaçırmamdan endişeliyim.

Mevcut çözümlerin sadece düzgün bir şekilde test edilmesini ve sadece bir araya getirilmemesini sağlamak için uyulması gereken herhangi bir süreç / adım var mı? Testlerin iyi kalitede olmasını ve sadece herhangi bir test vakasının test olmamasından daha iyi olmadığından nasıl emin olabilirim .

Ben de sorduğum şey;

• Üretimde olan mevcut bir çözüm için çabaya değer mi?
• Bu proje için yapılan testleri göz ardı etmek ve gelecekteki olası bir yeniden yazmaya eklemek daha iyi olur mu?
• Daha faydalı ne olacak; birkaç hafta test ekleyerek veya birkaç hafta işlevsellik ekleyerek mi geçiriyorsunuz?

(Açıkçası üçüncü noktaya verilen cevap tamamen yönetime mi yoksa geliştiriciye mi konuştuğunuza bağlıdır)

Ödül Nedeni

Sadece daha iyi bir şey olduğuna dair şüphe duymakla kalmayıp, aynı zamanda buna karşı bazı iyi nedenleri doğrulamak için daha geniş bir cevap yelpazesini denemek ve çekmek için bir ödül eklemek.

Bu soruyu daha sonra, ürünün gelecekteki gelişimini TDD'ye taşımak için adam saatlerini harcamaya değer olduğunu göstermeye çalışmak için artıları ve eksileriyle yazmayı amaçlıyorum. Bu zorluğa yaklaşmak ve kendi önyargılı bakış açım olmadan mantığımı geliştirmek istiyorum.

Daha önce sahip olmayan kod tabanlarına birim testleri tanıttım. Katıldığım son büyük proje, takıma geldiğimde, ürün sıfır birim testlerle zaten üretiliyordu. Ben ayrıldığımda - 2 yıl sonra - 230 000 + üretim LOC (gerçek zamanlı finansal Win-Formlar uygulaması) ile bir kod tabanında yaklaşık% 33 kod kapsamı sağlayan 4500+ veya daha fazla test yaptık. Bu kulağa düşük gelebilir, ancak sonuç kod kalitesi ve hata hızında önemli bir iyileşme ile birlikte moral ve karlılıkta iyileşme olmuştur.

İlgili taraflardan hem doğru bir anlayışa hem de bağlılığa sahip olduğunuzda yapılabilir.

Her şeyden önce, birim testinin kendi başına bir beceri olduğunu anlamak önemlidir. "Geleneksel" standartlara göre çok üretken bir programcı olabilirsiniz ve yine de daha büyük bir projede ölçeklenecek şekilde birim testleri yazmakta zorlanabilirsiniz.

Ayrıca, ve özellikle sizin durumunuz için, mevcut bir kod tabanına testi olmayan birim testleri eklemek de kendi başına uzman bir beceridir. Siz veya ekibinizdeki bir kişi mevcut bir kod tabanına birim testleri uygulama konusunda başarılı bir deneyime sahip olmadıkça, Feather'ın kitabını okumak bir gerekliliktir (isteğe bağlı veya şiddetle tavsiye edilmez) diyebilirim .

Kodunuzu birim testine geçirmek, kod tabanının kalitesi kadar insanlara ve becerilere yapılan bir yatırımdır. Bunu anlamak zihniyet ve beklentileri yönetmek açısından çok önemlidir.

Şimdi, yorumlarınız ve sorularınız için:

Bununla birlikte, TDD'yi en başından itibaren kullansaydım, büyük resmi kaçırmam ve nihai temel testleri kaçırmamdan endişeliyim.

Kısa cevap: Evet, testleri kaçırırsınız ve evet başlangıçta yeşil alan durumunda ne gibi görünmeyebilirler.

Daha derin seviyedeki cevap şudur: Önemli değil. Test olmadan başlarsınız. Testler eklemeye başlayın ve ilerledikçe yeniden düzenleme yapın. Beceri seviyeleri iyileştikçe, projenize eklenen tüm yeni kodlar için çıtayı yükseltmeye başlayın. Geliştirmeye devam et vb ...

Şimdi, buradaki satırlar arasında okurken, bunun "hareket etmemek için bir bahane olarak mükemmellik" zihniyetinden geldiği izlenimini edindim. Daha iyi bir zihniyet, kendine güvene odaklanmaktır. Bu yüzden henüz nasıl yapılacağını bilmediğiniz için, gittiğinizde ve boşlukları nasıl doldurduğunuzu anlayacaksınız. Bu nedenle endişelenmenize gerek yok.

Yine, bu bir yetenek. Lineer bir şekilde tek bir "süreç" veya "adım adım" yemek kitabı yaklaşımı ile sıfır testlerden TDD mükemmeliyetine geçemezsiniz. Bu bir süreç olacak. Beklentileriniz kademeli ve artımlı ilerleme ve iyileştirme yapmak olmalıdır. Sihirli hap yok.

İyi haber şu ki, aylar (ve hatta yıllar) geçtikçe, kodunuz yavaş yavaş "uygun" iyi faktörlü ve iyi test edilmiş kod olmaya başlayacaktır.

Yan not olarak. Eski bir kod tabanına birim testleri yerleştirmenin önündeki engelin, uyum eksikliği ve aşırı bağımlılıklar olduğunu göreceksiniz. Bu nedenle, muhtemelen en önemli becerinin, gerçek birim testlerini kendileri yazmak yerine mevcut bağımlılıkları ve kod çözmeyi nasıl kıracağını göreceksiniz.

Mevcut çözümlerin düzgün bir şekilde birim test edildiğinden ve yalnızca bir araya getirilmediğinden emin olmak için uyulması gereken herhangi bir işlem / adım var mı?

Zaten sahip değilseniz, bir yapı sunucusu kurun ve kod kapsamındaki tüm birim testleri de dahil olmak üzere her check-in'de çalışan sürekli bir entegrasyon yapısı kurun.

Çalışanlarınızı eğitin.

Bir yerden başlayın ve müşterinin bakış açısından ilerleme kaydederken testler eklemeye başlayın (aşağıya bakın).

Kod kapsamını, üretim kodu tabanınızın ne kadarının test edildiğini gösteren bir kılavuz olarak kullanın.

Yapım süresi her zaman HIZLI olmalıdır. Yapım süreniz yavaşsa, birim test becerileriniz gecikmektedir. Yavaş testleri bulun ve geliştirin (üretim kodunu ayırın ve ayrı ayrı test edin). İyi yazılmış, kolayca binlerce ünite testine sahip olmanız ve hala 10 dakikadan kısa bir sürede bir yapıyı tamamlayabilmeniz gerekir (~ 1-birkaç ms / test iyi ama çok kaba bir kılavuzdur, yansıma kullanarak kod gibi bazı istisnalar uygulanabilir. ).

Kontrol edin ve uyarlayın.

Testlerin iyi kalitede olmasını ve sadece herhangi bir test vakasının test olmamasından daha iyi olmadığından nasıl emin olabilirim.

Kendi yargınız birincil gerçeklik kaynağınız olmalıdır. Becerinin yerini tutabilecek bir metrik yoktur.

Bu deneyim veya yargıya sahip değilseniz, bunu yapan biriyle sözleşme yapmayı düşünün.

İki kaba ikincil gösterge, toplam kod kapsamı ve oluşturma hızıdır.

Üretimde olan mevcut bir çözüm için çabaya değer mi?

Evet. Özel yapım bir sistem veya çözüme harcanan paranın büyük çoğunluğu üretime alındıktan sonra harcanır. Ve kaliteye yatırım yapmak, insanlar ve beceriler asla modası geçmiş olmamalıdır.

Bu proje için yapılan testleri göz ardı etmek ve gelecekteki olası bir yeniden yazmaya eklemek daha iyi olur mu?

Sadece insanlara ve becerilere yapılan yatırımı değil, en önemlisi toplam sahip olma maliyetini ve sistemin beklenen yaşam süresini dikkate almanız gerekir.

Davaların çoğunda kişisel cevabım "evet" olurdu, çünkü bunun çok daha iyi olduğunu biliyorum, ama istisnalar olabileceğini kabul ediyorum.

Daha faydalı ne olacak; birkaç hafta test ekleyerek veya birkaç hafta işlevsellik ekleyerek mi geçiriyorsunuz?

Ne. Yaklaşımınız işlevsellik açısından ilerleme kaydederken kod tabanınıza testler eklemek olmalıdır.

Yine, insanlara, becerilere ve kod tabanının kalitesine yapılan bir yatırımdır ve bu nedenle zaman gerektirecektir. Ekip üyelerinin bağımlılıkları nasıl kıracaklarını, birim testlerini nasıl yazacaklarını, yeni alışkanlıkları öğreneceklerini, disiplini ve kalite bilincini nasıl geliştireceklerini, yazılımı nasıl daha iyi tasarlayacaklarını vb. Öğrenmeleri gerekir. Testleri eklemeye başladığınızda, ekip üyelerinizin muhtemelen Bu becerilerin henüz bu yaklaşımın başarılı olması için olması gereken düzeyde olması, bu nedenle çok fazla test eklemek için tüm zaman harcamak için ilerlemeyi durdurmak işe yaramaz.

Ayrıca, mevcut herhangi bir büyüklükteki proje boyutunda mevcut bir kod tabanına birim testleri eklemek, taahhüt ve kararlılık gerektiren BÜYÜK bir girişimdir. Temel bir şeyi değiştiremezsiniz, yolda çok fazla öğrenmeyi bekleyemezsiniz ve iş değerinin akışını durdurarak sponsorunuzdan herhangi bir YG beklemesini isteyemezsiniz. Bu uçmayacak ve açıkçası olmamalı.

Üçüncüsü, ekibinize sağlam iş odak değerleri aşılamak istiyorsunuz. Kalite asla müşteri pahasına olmaz ve kalite olmadan hızlı gidemezsiniz. Ayrıca, müşteri değişen bir dünyada yaşıyor ve işiniz onun uyum sağlamasını kolaylaştırmak. Müşteri uyumu hem kalite hem de iş değeri akışını gerektirir.

Yaptığınız şey teknik borcu ödemek. Siz de müşterilerinize sürekli değişen ihtiyaçlarınızı karşılarken bunu yapıyorsunuz. Kademeli olarak borç ödendikçe durum iyileşir ve müşteriye daha iyi hizmet vermek ve daha fazla değer sunmak daha kolaydır. Vb Bu olumlu momentum, hedeflemeniz gereken şeydir çünkü sürdürülebilir ilerleme ilkelerinin altını çizer ve hem geliştirme ekibiniz, müşteriniz, hem de paydaşlarınız için ahlaki değeri koruyacak ve geliştirecektir.

umarım yardımcı olur

• Üretimde olan mevcut bir çözüm için çabaya değer mi?

Evet!

• Bu proje için yapılan testleri göz ardı etmek ve gelecekteki olası bir yeniden yazmaya eklemek daha iyi olur mu?

Hayır!

• Daha faydalı ne olacak; birkaç hafta test ekleyerek veya birkaç hafta işlevsellik ekleyerek mi geçiriyorsunuz?

Test (özellikle otomatik test) eklemek , projenin gelecekte çalışmaya devam etmesini çok daha kolay hale getirir ve kullanıcıya aptalca sorunların gönderilme olasılığını önemli ölçüde azaltır.

Önceden koymak için yapılan testler , kodunuzun (ve içindeki her bir modülün) genel arayüzünün düşündüğünüz şekilde çalışıp çalışmadığını kontrol eden testlerdir . Mümkünse, kod modüllerinizin sahip olması gereken her izole hata modunu da başlatmayı deneyin (bunun önemsiz olabileceğini unutmayın ve işlerin nasıl başarısız olduğunu çok dikkatli bir şekilde kontrol etmemeye dikkat etmelisiniz, örneğin, gerçekten istemiyorsunuz hiç oturum açıldığını doğrulamak yeterli olduğundan, başarısızlıkla üretilen günlük mesajı sayısını saymak gibi şeyler yapmak yeterlidir).

Daha sonra bug veritabanınızdaki her bir hata için tam olarak hataya neden olan ve hata düzeltildiğinde geçecek bir test yapın. Sonra bu hataları düzeltin! :-)

Testler eklemek için zamana mal olur, ancak kodunuz çok daha yüksek kalitede olduğu için arka uçta birçok kez geri ödersiniz. Yeni bir sürüm göndermeye veya bakım yapmaya çalıştığınızda bu çok önemlidir.

Ünite iyileştirme problemi, buraya bir bağımlılık enjekte etmeyi veya orada bir arayüz kullanmayı düşünmediğinizi fark edeceksiniz ve çok geçmeden tüm bileşeni yeniden yazacağınızı fark edeceksiniz. Bunu yapmak için zamanınız varsa, kendinize güzel bir güvenlik ağı oluşturacaksınız, ancak yol boyunca ince hatalar getirmiş olabilirsiniz.

İlk günden itibaren birim testlere gerçekten ihtiyaç duyan birçok projeye katıldım ve kodları çalışmaya ve para kazanmaya genellikle haklı çıkamayan, tam bir yeniden yazmadan kısa bir süre içinde onları almanın kolay bir yolu yok. Son zamanlarda, kodu ortaya çıkar çıkmaz bir kusuru yeniden oluşturacak şekilde kullanan powershell komut dosyaları yazmaya ve daha sonra bu komutları daha fazla değişiklik için regresyon testleri paketi olarak tutmaya başvurdum. Bu şekilde, en azından çok fazla değiştirmeden uygulama için bazı testler oluşturmaya başlayabilirsiniz, ancak bunlar, uygun birim testlerinden çok uçtan uca regresyon testlerine benzer.

Herkesin söylediklerine katılıyorum. Mevcut koda test eklemek değerlidir. Bu noktaya asla katılmayacağım, ama bir uyarı eklemek istiyorum.

Mevcut koda test eklemek değerli olsa da, bir bedeli vardır. Bu pahasına geliyor değil yeni özellikleri bina. Bu iki şeyin nasıl dengelendiği tamamen projeye bağlıdır ve bir dizi değişken vardır.

• Tüm bu kodları test etmeniz ne kadar sürer? Gün? Haftalar? Aylar? Yıl?
• Bu kodu kime yazıyorsunuz? Ödeme yapan müşteriler mi? Profesör? Açık kaynaklı bir proje mi?
• Programınız nasıl? Karşılaşmanız gereken zor tarihler var mı? Hiç teslim tarihiniz var mı?

Tekrar vurgulayayım, testler değerlidir ve eski kodunuzu test etmek için çalışmalısınız. Bu daha çok ona nasıl yaklaştığınızla ilgili. Her şeyi bırakmayı ve tüm eski kodunuzu test etmeyi göze alabiliyorsanız, yapın. Bu gerçekçi değilse, en azından yapmanız gerekenler

• Yazdığınız tüm yeni kodlar tamamen birim testinde olmalıdır
• Dokunduğunuz eski kodlar (hata düzeltme, uzantı vb.) Birim testine tabi tutulmalıdır.

Ayrıca, bu bir ya hep ya hiç önerisi değildir. Diyelim ki, dört kişiden oluşan bir ekibiniz varsa ve bir veya iki kişiyi eski test görevine koyarak son tarihlerinizi karşılayabilirsiniz, elbette bunu yapın.

Düzenle:

Bu soruyu daha sonra, ürünün gelecekteki gelişimini TDD'ye taşımak için adam saatlerini harcamaya değer olduğunu göstermeye çalışmak için artıları ve eksileriyle yazmayı amaçlıyorum.

Bu, "Kaynak kontrolünü kullanmanın artıları ve eksileri nelerdir?" veya "İnsanları işe almadan önce röportaj yapmanın artıları ve eksileri nelerdir?" veya "Nefes almanın artıları ve eksileri nelerdir?"

Bazen tartışmanın sadece bir tarafı vardır. Herhangi bir karmaşıklığa sahip herhangi bir proje için bir tür otomatik teste sahip olmanız gerekir. Hayır, testler kendilerini yazmaz ve evet, işleri kapıdan çıkarmak biraz zaman alır. Ancak uzun vadede, hataları test etmek için daha fazla zaman alacak ve daha fazla paraya mal olacak. Dönemi. Hepsi bu kadar.

Test eklemeye başladığımızda, kullanıcı arayüzünde ve raporlama kodunda çok fazla mantığa sahip, on yaşında, yaklaşık milyon satırlık bir kod tabanıydı.

Yaptığımız ilk şeylerden biri (sürekli bir yapı sunucusu kurduktan sonra) regresyon testleri eklemekti. Bunlar uçtan uca testlerdi.

• Her test takımı, veritabanını bilinen bir duruma başlatarak başlar. Aslında Subversion'da tuttuğumuz düzinelerce regresyon veri setimiz var (sırf boyutu nedeniyle kodumuzdan ayrı bir depoda). Her testin FixtureSetUp değeri bu regresyon veri kümelerinden birini geçici bir veritabanına kopyalar ve oradan çalışır.
• Test fikstürü kurulumu daha sonra sonuçları ilgilendiğimiz bazı işlemleri çalıştırır. (Bu adım isteğe bağlıdır - bazı regresyon testleri sadece raporları test etmek için mevcuttur.)
• Daha sonra her test bir rapor çalıştırır, raporu bir .csv dosyasına gönderir ve bu .csv içeriğini kaydedilmiş bir anlık görüntü ile karşılaştırır. Bu anlık görüntü .csvs, her regresyon veri kümesinin yanında Subversion'da depolanır. Rapor çıktısı kaydedilen anlık görüntü ile eşleşmezse, test başarısız olur.

Regresyon testlerinin amacı size bir şeyin değişip değişmediğini söylemektir. Bu, bir şeyi kırdığınızda başarısız oldukları anlamına gelir, ancak bir şeyi bilerek değiştirdiyseniz de başarısız olurlar (bu durumda düzeltme, anlık görüntü dosyasını güncellemektir). Anlık görüntü dosyalarının bile doğru olduğunu bilmiyorsunuz - sistemde hatalar olabilir (ve sonra bu hataları düzelttiğinizde, regresyon testleri başarısız olur).

Bununla birlikte, regresyon testleri bizim için büyük bir kazançtı. Sistemimizdeki hemen hemen her şeyin bir raporu vardır, bu nedenle raporların çevresinde birkaç hafta boyunca bir test koşumu alarak, kod tabanımızın büyük bir kısmı üzerinde bir miktar kapsama alanı elde edebildik. Eşdeğer birim testlerinin yazılması aylar veya yıllar alacaktır. (Birim testleri bize çok daha iyi bir kapsama sahip olacaktı ve çok daha az kırılgan olurdu; ama mükemmellik için yıllarca beklemek yerine şimdi bir şey yapmayı tercih ederim.)

Sonra geri döndük ve hataları düzelttiğimizde veya geliştirmeler eklediğimizde veya bazı kodları anlamak gerektiğinde birim testleri eklemeye başladık. Regresyon testleri hiçbir şekilde birim test ihtiyacını ortadan kaldırmaz; onlar olsun böylece, sadece birinci düzey güvenlik ağı konum bazı hızlı test kapsamının düzeyini. Sonra bağımlılıkları kırmak için yeniden düzenleme başlayabilirsiniz, böylece birim testleri ekleyebilirsiniz; ve regresyon testleri size yeniden düzenlemenizin hiçbir şeyi bozmadığına dair güven verir.

Regresyon testlerinin sorunları vardır: yavaştırlar ve kırılmalarının çok fazla nedeni vardır. Ama bizim için en azından onlar bu yüzden buna değer. Son beş yılda sayısız böcek yakaladılar ve KG döngüsünü beklemek yerine birkaç saat içinde yakaladılar. Hala orijinal regresyon testlerimiz var, yedi farklı sürekli üretim makinesine yayılmış (hızlı birim testlerini çalıştıran makineden ayrı olarak) ve hatta bunlara zaman zaman ekliyoruz, çünkü hala 6000 kodumuz var. + birim testleri kapsamaz.

Kesinlikle buna değer. Uygulamamız karmaşık çapraz doğrulama kurallarına sahiptir ve son zamanlarda iş kurallarında önemli değişiklikler yapmak zorunda kaldık. Kullanıcının kaydetmesini engelleyen çakışmalarla sonuçlandık. Sonsuza kadar applcation sıralamak için olacağını fark (sadece sorunların olduğu noktaya ulaşmak için birkaç dakika sürer). Otomatik birim testleri uygulamak istedim ve çerçeveyi kurdum, ancak işlerin çalıştığından emin olmak için birkaç sahte testin ötesinde bir şey yapmamıştım. Elimizdeki yeni iş kuralları ile testler yazmaya başladım. Testler, çatışmalara neden olan koşulları hızla belirledi ve kuralları açıklığa kavuşturduk.

Eklediğiniz veya değiştirdiğiniz işlevselliği kapsayan testler yazarsanız, derhal faydalanırsınız. Yeniden yazma için beklerseniz, hiçbir zaman otomatik testleriniz olmayabilir.

Zaten çalışan mevcut şeyler için testler yazmak için çok zaman harcamamalısınız. Çoğu zaman, mevcut kod için bir spesifikasyonunuz yoktur, bu nedenle test ettiğiniz ana şey tersine mühendislik yeteneğinizdir. Öte yandan, bir şeyi değiştirecekseniz, değişiklikleri doğru yaptığınızı bilmeniz için bu işlevselliği testlerle örtmeniz gerekir. Ve elbette, yeni işlevler için başarısız olan testler yazın, sonra eksik işlevselliği uygulayın.

Sesimi ekleyeceğim ve evet diyeceğim, her zaman yararlı!

Ancak aklınızda bulundurmanız gereken bazı farklılıklar vardır: kara kutuya karşı beyaz kutuya ve üniteye karşı işlevsel. Tanımlar değiştiğinden, bunlar ile kastettiğim:

• Kara kutu = Uygulamaların özel bilgisi olmadan yazılan, genellikle saf bir kullanıcının beklediğinden emin olmak için uç noktalarda dolaşan testler.
• Beyaz-box yazılır testleri = ile sık sık tanınmış başarısızlık noktaları egzersiz deneyin uygulanması, bilgi.
• Birim testleri = bireysel birimlerin testleri (fonksiyonlar, ayrılabilir modüller, vb.). Örneğin: dizi sınıfınızın beklendiği gibi çalıştığından ve dize karşılaştırma işlevinizin çok çeşitli girdiler için beklenen sonuçları döndürdüğünden emin olun.
• İşlevsel testler = tüm sistemin bir kerede testleri. Bu testler aynı anda sistemin büyük bir kısmını kullanacaktır. Örneğin: init, bir bağlantı açın, gerçek dünyadan bazı şeyler yapın, kapatın, sonlandırın. Bunlar ve birim testleri arasında bir ayrım yapmayı seviyorum, çünkü farklı bir amaca hizmet ediyorlar.

Oyunun sonlarına doğru bir nakliye ürününe testler eklediğimde, beyaz kutu ve fonksiyonel testlerden kova için en çok patlamayı aldığımı buldum . Kodun özellikle kırılgan olduğunu bildiğiniz herhangi bir kısmı varsa, iki kez aynı şekilde kırılmadığından emin olmak için sorunlu durumları kapsayacak şekilde beyaz kutu testleri yazın. Benzer şekilde, tüm sistem fonksiyonel testleri, en sık kullanılan 10 kullanım durumunu asla kırmamanıza yardımcı olan kullanışlı bir sağlık kontrolüdür.

Küçük birimlerin kara kutu ve birim testleri de yararlıdır, ancak zamanınız sınırlıysa, bunları erken eklemek daha iyidir. Gönderdiğiniz zaman, genellikle bu testlerin bulabileceği en önemli vakaların ve sorunların çoğunu (zor yoldan) buldunuz.

Diğerleri gibi size TDD ile ilgili en önemli iki şeyi de hatırlatacağım:

1. Test oluşturmak sürekli bir iştir. Asla durmaz. Her yeni kod yazdığınızda veya mevcut kodu değiştirdiğinizde yeni testler eklemeyi denemelisiniz.
2. Test takımınız asla yanılmaz! Testlerinizin sizi yanlış bir güvenlik hissine sürüklemesine izin vermeyin. Test paketini geçmesi, düzgün çalıştığı veya ince bir performans gerilemesi vb. Getirmediğiniz anlamına gelmez.

Üretimde olan bir uygulamaya birim testleri eklemeye değip değmeyeceği, uygulamanın bakım maliyetine bağlıdır. Uygulamanın birkaç hata ve geliştirme isteği varsa, belki de çabaya değmez. OTOH, uygulama hatalıysa veya sık sık değiştirilirse, birim testleri büyük ölçüde faydalı olacaktır.

Bu noktada, ünite testlerini seçici olarak eklemekten bahsettiğimi, baştan TDD uygularsanız mevcut olanlara benzer bir test paketi oluşturmaya çalışmadığımı unutmayın. Bu nedenle, ikinci sorunuzun ikinci yarısına yanıt olarak: ister yeni bir proje ister yeniden yazma olsun (özür dileyin, ancak burada gerçekten okumalısınız başka bir kitabın bağlantısı) : Testler Rehberliğinde Büyüyen Nesne Odaklı Yazılımlar )

Üçüncü sorunuza cevabım birinciyle aynı: projenizin içeriğine bağlı.

Gönderinize gömülü olarak, geriye dönük takılmış testlerin düzgün bir şekilde yapılmasını sağlamakla ilgili başka bir soru vardır . Sağlanması gereken önemli şey, birim testlerin gerçekten birim testler olmasıdır ve bu (daha sık olmamakla birlikte), yenileme testlerinin, katmanlarınızın / bileşenlerin ayrılmasını sağlamak için mevcut kodun yeniden düzenlenmesini gerektirdiği anlamına gelir (bkz. Bağımlılık enjeksiyonu; kontrolün ters çevrilmesi; stubbing; alaycı). Bunu uygulayamazsanız, testleriniz, kullanışlı, ancak daha az hedefli ve gerçek birim testlerinden daha kırılgan olan entegrasyon testleri haline gelir.

Uygulama dilinden bahsetmiyorsunuz, ancak Java'da bu yaklaşımı deneyebilirsiniz:

1. Ayrı bir kaynak ağacında, bunları oluşturmak için bir araç kullanarak regresyon veya 'duman' testleri oluşturun, bu da sizi% 80'e yakın kapsama alanı sağlayabilir. Bu testler tüm kod mantığı yollarını yürütür ve bu noktadan sonra kodun halen tam olarak ne yaptığını doğrular (bir hata olsa bile). Bu, kodu elle kolayca test edilebilir hale getirmek için gerekli yeniden düzenleme işlemini yaparken yanlışlıkla değiştirilen davranışlara karşı bir güvenlik ağı sağlar.

   • Ürün önerisi - Junit Factory ücretsiz web tabanlı ürünü kullanıyordum, ama ne yazık ki şimdi kapalı. Bununla birlikte, ürün http://www.agitar.com/solutions/products/automated_junit_generation.html adresindeki ticari olarak lisanslı AgitarOne JUnit Generator'da yaşıyor

2. Bundan sonra eklediğiniz her hata veya özellik için, yeni kodun test edilebilir olacak şekilde tasarlandığından emin olmak için bir TDD yaklaşımı kullanın ve bu testleri normal bir test kaynağı ağacına yerleştirin.

3. Yeni kod eklemenin bir parçası olarak test edilebilir hale getirmek için mevcut kodun da değiştirilmesi veya yeniden düzenlenmesi gerekecektir; duman testleriniz, regresyonlara veya yanlışlıkla davranışlardaki ince değişikliklere karşı bir güvenlik ağı verecektir.

4. TDD aracılığıyla değişiklik yaparken (hata düzeltmeleri veya özellikler), tamamlandığında tamamlayıcı duman testi başarısız olabilir. Yapılan değişiklikler nedeniyle arızaların beklendiği gibi olduğunu doğrulayın ve daha az okunabilir duman testini kaldırın, çünkü elle yazılmış birim testiniz bu iyileştirilmiş bileşenin tamamını kapsamaktadır. Test kapsamınızın yalnızca aynı kalmasını veya artmasını reddetmediğinden emin olun.

5. Hataları düzeltirken, önce hatayı ortaya çıkaran başarısız bir birim testi yazın.

Bu cevaba, birim testinin gerçekten önemli olduğunu söyleyerek başlamak istiyorum, çünkü üretime geçmeden önce hataları tutmanıza yardımcı olacaktır.

Hataların yeniden tanıtıldığı alan projelerini / modüllerini tanımlayın. test yazmak için bu projelerle başlayın. Yeni işlevsellik ve hata düzeltme için testler yazmak mükemmeldir.

Üretimde olan mevcut bir çözüm için çabaya değer mi?

Evet. Hataların azaldığını ve bakımın kolaylaştığını göreceksiniz

Bu proje için yapılan testleri göz ardı etmek ve gelecekteki olası bir yeniden yazmaya eklemek daha iyi olur mu?

Eğer şimdi başlamanızı tavsiye ederim.

Daha faydalı ne olacak; birkaç hafta test ekleyerek veya birkaç hafta işlevsellik ekleyerek mi geçiriyorsunuz?

Yanlış soruyu soruyorsun. Kesinlikle, işlevsellik her şeyden daha önemlidir. Ancak, test eklemek için birkaç hafta harcamanın sistemimi daha kararlı hale getirip getirmeyeceğini sormalısınız. Bu son kullanıcıya yardımcı olacak mı? Ekipteki yeni bir geliştiricinin projeyi anlamasına ve aynı zamanda bir değişikliğin genel etkisinin anlaşılmaması nedeniyle bir hata yaratmamasına yardımcı olacak mı?

Nerede yeniden düzenlemeye başlayacağım sorusunun bir cevabı olarak Refactor Low-Hang Fruit'i çok severim . Çiğneyebileceğinizden daha fazla ısırmadan daha iyi tasarıma gitmenin bir yolu.

Aynı mantık TDD için de geçerlidir - ya da sadece birim testleri: ihtiyacınız olan testleri, ihtiyacınız olduğu gibi yazın; yeni kod için test yazma; görünen hatalar için testler yazın. Kod tabanının ulaşılması zor alanlarını ihmal etmekten endişe duyuyorsunuz ve bu kesinlikle bir risk, ancak başlamanın bir yolu olarak: başlayın! Kod kapsamı araçlarıyla yoldaki riski azaltabilirsiniz ve risk (bence) bu kadar büyük değil, yine de: eğer hataları kaplıyorsanız, yeni kodu kaplıyor, baktığınız kodu kaplıyor , o zaman testlere en fazla ihtiyacı olan kodu kapsıyorsunuz.

• Evet öyle. yeni işlevsellik eklemeye başladığınızda, bazı eski kod değişikliklerine neden olabilir ve sonuç olarak potansiyel hataların kaynağıdır.
• yeni işlevsellik eklemeye başlamadan önce (ilkine bakın) tüm (veya neredeyse) kodlar (ideal olarak) birim testleri kapsamında olmalıdır.
• (birinci ve ikinci olana bakınız) :). yeni görkemli bir işlevsellik eski çalışan kodu "yok edebilir".

Evet yapabilir: Şu andan itibaren yazdığınız tüm kodların yerinde bir test olduğundan emin olun.

Halihazırda mevcut olan kodun değiştirilmesi ve test edilebilmesi gerekiyorsa, bunu yapın, ancak kararlı kod için testler almaya çalışırken çok güçlü olmamak daha iyidir. Bu tür şeyler vuruntu etkisine sahip olma eğilimindedir ve kontrolden çıkabilir.

Üretimde olan mevcut bir çözüm için çabaya değer mi?

Bu proje için yapılan testleri göz ardı etmek ve gelecekteki olası bir yeniden yazmaya eklemek daha iyi olur mu?

Daha faydalı ne olacak; birkaç hafta test ekleyerek veya birkaç hafta işlevsellik ekleyerek mi geçiriyorsunuz?

Güncelleme

Orijinal cevaptan 6 yıl sonra, biraz farklı bir tutum aldım.

Yazdığınız tüm yeni koda birim testleri eklemenin mantıklı olduğunu düşünüyorum - ve sonra bunları test edilebilir yapmak için değişiklikler yaptığınız yerleri yeniden düzenleyin.

Mevcut kodunuz için tek seferde test yazmak yardımcı olmaz - ancak yazdığınız yeni kod (veya değiştirdiğiniz alanlar) için test yazmamak da mantıklı değildir. Bir şeyi yeniden düzenledikçe / ekledikçe testler eklemek muhtemelen testler eklemenin ve kodu testsiz mevcut bir projede daha sürdürülebilir hale getirmenin en iyi yoludur.

Daha erken cevap

Burada birkaç kaş kaldıracağım :)

Her şeyden önce projeniz nedir - eğer bir derleyici veya bir dil veya bir çerçeve veya uzun süre işlevsel olarak değişmeyecek başka bir şeyse, o zaman birim testleri eklemek kesinlikle harika.

Bununla birlikte, muhtemelen işlevsellikte değişiklikler gerektirecek bir uygulama üzerinde çalışıyorsanız (değişen gereksinimler nedeniyle), bu ekstra çaba sarf etmenin bir anlamı yoktur.

Neden?

1. Birim testleri yalnızca kod testlerini kapsar - kod tasarlandığını yaparsa yap - yine de yapılması gereken manuel testlerin yerini almaz (fonksiyonel hataları, kullanılabilirlik sorunlarını ve diğer tüm sorunları ortaya çıkarmak için)

2. Birim testleri maliyetlidir! Şimdi nereden geliyorum, bu değerli bir mal - ve iş genellikle tam bir test paketi üzerinde daha iyi işlevsellik seçer.

3. Uygulamanız kullanıcılar için uzaktan bile faydalıysa, değişiklik talep edeceklerdir - böylece işleri daha iyi, daha hızlı ve muhtemelen yeni şeyler yapacak sürümlere sahip olacaksınız - kodunuz büyüdükçe çok fazla yeniden düzenleme olabilir. Dinamik bir ortamda tam yetişkin ünite test takımını korumak baş ağrısıdır.

4. Birim testleri ürününüzün algılanan kalitesini etkilemez - kullanıcının gördüğü kalite. Elbette, yöntemleriniz tam olarak ilk günkü gibi çalışabilir, sunum katmanı ve iş katmanı arasındaki arayüz bozulmamış olabilir - ama tahmin edin ne oldu? Kullanıcı umursamıyor! Uygulamanızı test etmek için bazı gerçek test kullanıcıları edinin. Ve çoğu zaman, bu yöntemler ve arayüzler, er ya da geç, yine de değişmelidir.

Daha faydalı ne olacak; birkaç hafta test ekleyerek veya birkaç hafta işlevsellik ekleyerek mi geçiriyorsunuz? - Test yazmaktan daha iyi yapabileceğiniz çok şey var - Yeni işlevsellik yazın, performansı artırın, kullanılabilirliği artırın, daha iyi yardım kılavuzları yazın, bekleyen hataları çözün, vb.

Şimdi beni yanlış anlamayın - Gelecek 100 yıl boyunca değişmeyeceğinden kesinlikle eminseniz, devam edin, kendinizi öldürün ve bu testleri yazın. Otomatik Testler, üçüncü taraf kodlarını kesinlikle kırmak istemediğiniz API'lar için de harika bir fikirdir. Başka her yerde, daha sonra beni gemi yapan bir şey!

Önemli ölçüde test kapsamına sahip olmanız pek olası değildir, bu nedenle testleri nereye eklediğiniz konusunda taktik olmalısınız:

• Bahsettiğiniz gibi, bir hata bulduğunuzda, bir test yazmak (yeniden üretmek için) ve ardından hatayı düzeltmek için iyi bir zamandır. Testin hatayı yeniden oluşturduğunu görürseniz, bunun iyi ve benzer bir test olduğundan emin olabilirsiniz. Böceklerin büyük bir bölümünün regresyonlar (% 50?) Olduğu düşünüldüğünde, neredeyse her zaman regresyon testleri yazmaya değer.
• Kodu değiştirmek için bir kod alanına girdiğinizde, etrafındaki testleri yazmak için iyi bir zamandır. Kodun niteliğine bağlı olarak, farklı testler uygundur. İyi bir tavsiye burada bulunabilir .

OTOH, sadece insanların mutlu olduğu kodların etrafındaki testler yazmaya oturmaya değmez - özellikle de hiç kimse değiştirmeyecekse. Sadece değer katmaz (belki de sistemin davranışını anlamak dışında).

İyi şanslar!

Başka bir kitap almak istemediğini söylüyorsun. Michael Feather'ın eski kodla etkili bir şekilde çalışma hakkındaki makalesini okuyun . Sonra kitabı satın al :)

Yerinizde olsaydım, muhtemelen tüm sistemi uygulayan fonksiyonel testlerden başlayarak dışarıdan bir yaklaşım alırdım. RSpec gibi bir BDD belirtim dili kullanarak sistemin gereksinimlerini yeniden belgelemeye ve daha sonra kullanıcı arabirimini otomatikleştirerek bu gereksinimleri doğrulamak için testler yazmaya çalışırdım.

Sonra yeni keşfedilen böcekler için kusur odaklı geliştirme, sorunları yeniden üretmek için birim testleri yazma ve testler geçinceye kadar böcek üzerinde çalışmak istiyorum.

Yeni özellikler için, dışarıdan gelen yaklaşıma sadık kalacağım: RSpec'te belgelenen ve kullanıcı arayüzünü otomatikleştirerek (elbette başlangıçta başarısız olacak) doğrulanan özelliklerle başlayın, ardından uygulama ilerledikçe daha ince taneli birim testleri ekleyin.

Süreç konusunda uzman değilim, ancak ne kadar az deneyime sahip olduğumdan, otomatik UI testi yoluyla BDD'nin kolay olmadığını söyleyebilirim, ancak bence çabaya değer ve muhtemelen davanızdan en fazla yararı sağlayacak.

Hiçbir şekilde tecrübeli bir TDD uzmanı değilim, ama tabii ki test edebildiğiniz kadarıyla inanılmaz derecede önemli olduğunu söyleyebilirim. Kod zaten yerinde olduğundan, bir tür birim test otomasyonu uygulayarak başlardım. TeamCity'yi projelerimdeki tüm testleri uygulamak için kullanıyorum ve bileşenlerin nasıl yapıldığına dair güzel bir özet sunuyor.

Bu durumda, başarısız olamayacak gerçekten kritik iş mantığı benzeri bileşenlere geçirdim. Benim durumumda, çeşitli girişler için çözülmesi gereken bazı temel trigometri problemleri var, bu yüzden bunlardan halkı test ediyorum. Bunu yapmamın nedeni, gece yarısı yağını yaktığımda, gerçekten dokunulması gerekmeyen kod derinliklerine kadar zaman harcamak çok kolay, çünkü olası tüm girdiler için test edildiğini biliyorsunuz (benim durumumda, sınırlı sayıda girdi var).

Tamam, şimdi umarım bu kritik parçalar hakkında daha iyi hissedersin. Oturup tüm testleri patlatmak yerine, ortaya çıktıklarında onlara saldırırdım. Düzeltmek için gerçek bir PITA olan bir hataya çarparsanız, bunun için birim testlerini yazın ve onları yoldan çıkarın.

Testin zor olduğunu düşündüğünüz durumlar vardır, çünkü testten belirli bir sınıfı başlatamazsınız, bu yüzden alay etmelisiniz. Oh, ama belki de kolayca alay edemezsin çünkü bir arayüze yazmadın. Bu "çemberler" senaryolarını adı geçen arayüzü uygulama fırsatı olarak görüyorum, çünkü bu iyi bir şey.

Oradan, inşa sunucunuzu veya bir kod kapsama aracı ile yapılandırılmış olan otomasyonunuzu alırsınız. Kötü kapsama alanına sahip olduğunuz büyük kırmızı bölgelere sahip kötü çubuk grafikler oluştururlar. Şimdi% 100 kapsama alanı hedefiniz değil,% 100 kapsama alanı da kodunuzun kurşun geçirmez olduğu anlamına gelmez, ancak boş zamanım olduğunda kırmızı çubuk kesinlikle beni motive eder. :)

Çok iyi cevaplar var, bu yüzden içeriklerini tekrar etmeyeceğim. Profilinizi kontrol ettim ve C # .NET geliştiricisi olduğunuz görülüyor. Bu nedenle, eski kod için otomatik üretim birimi testleri ile size yardımcı olabilecek Microsoft PEX ve Moles projesine referans ekliyorum . Otojenerasyonun en iyi yol olmadığını biliyorum ama en azından başlamanın yolu bu. Eski dergisi için PEX kullanımı hakkında MSDN dergisinden bu çok ilginç makaleye göz atın .

Test eklemeye nereden başlayacağınızı açıklayan bir TopTal Engineer tarafından mükemmel bir makale okumanızı öneririm : çok fazla matematik içerir, ancak temel fikir şudur:

1) Kodunuzun Afferent Coupling (CA) değerini ölçün (bir sınıfın diğer sınıflar tarafından ne kadar kullanıldığını, yani kırılması yaygın hasara neden olacağı anlamına gelir)

2) Kodunuzun Siklomatik Karmaşıklığını (CC ) ölçün (daha yüksek karmaşıklık = daha yüksek kırılma değişikliği)

Yüksek CA ve CC'ye sahip sınıfları tanımlamanız gerekir, yani f (CA, CC) işlevine sahip olmanız ve iki ölçüm arasında en küçük farkları olan sınıflara test kapsamı için en yüksek öncelik verilmelidir.

Neden? Çünkü yüksek bir CA ancak çok düşük CC sınıfları çok önemlidir, ancak kırılma olasılığı düşüktür. Öte yandan, düşük CA ancak yüksek CC'nin kırılması muhtemeldir, ancak daha az hasara neden olur. Yani dengelemek istiyorsunuz.

Bu bağlıdır ...
Birim testleri yapmak harikadır, ancak kullanıcılarınızın kim olduğunu ve daha hatasız bir ürün elde etmek için neyi tolere etmeye istekli olduklarını düşünmeniz gerekir. Kaçınılmaz olarak, şu anda birim testi olmayan kodunuzu yeniden düzenleyerek, hataları tanıtacaksınız ve birçok kullanıcı, uzun vadede daha az kusurlu hale getirmek için ürünü geçici olarak daha kusurlu hale getirdiğinizi anlamakta zorlanacak. Sonuçta son söyleyecek kullanıcılar ...

Evet. Hayır. Test ekleme.

Daha fazla TDD yaklaşımına gitmek, yeni işlevsellik ekleme ve regresyon testini daha kolay hale getirme çabalarınızı daha iyi bilgilendirecektir. Bunu kontrol et!