TDD'de topu yuvarlayın

En az 15 yıldır kullanımda olan bir uygulamayı korumak ve geliştirmek için diğer birçok ekiple birlikte çalışan bir geliştirici ekibinin parçasıyım. İlk inşa edildiğinde ve tasarlandığında TDD duyulmamıştı.

Uygulama oldukça kararlıdır ve nadiren bir gösteri durdurma hatasıyla karşılaşırız, ancak haftada bir veya iki hatayı ortalama olarak hizmet kalitesini ciddi şekilde düşürüyoruz. Bu hatalar, büyük ölçüde parmak işaretinden dolayı bulmak ve düzeltmek için sonsuza dek sürer ve sahip olduğumuz tek test arayüz testidir. Hata giderilmeden önce hatanın olduğu yerde avlanmak için çok fazla zaman harcadığından, ben ve başka bir geliştirici Test Odaklı Geliştirme önermek istiyoruz. Yakında yeni bir revizyon var ve yeni modüller üzerinde yapılan eksiksiz birim testlerinin neredeyse tamamını görmek istiyoruz, ayrıca eski olan değiştirmek zorunda olduğumuz herhangi bir kod için test birimleri oluşturmayı öneriyoruz (yani, hata düzeltme veya özellik uygulaması) ), ancak sorunlara neden olmayan kodlar için test senaryoları geliştirmek için zaman harcamaktan kaçının.

Bana göre bu makul görünüyor. Bu ay, düzeltilmesi iki hafta süren bir hatayla karşılaştık, ancak birim testi yapılsaydı konuşlandırılmadan önce tanımlanabilirdi. Ancak yöneticilerimize daha fazla para harcayacakları anlaşılıyor.

Müşterilerimizi birim test ve test odaklı geliştirme için para harcamak istediklerine nasıl ikna edebilirim? Birim testin yatırım getirisini gösteren çalışmalar var mı?

Tam gelişmiş TDD'nin eski bir koda doğrudan dahil edilmesi, bakım projesinin çok zor satılmasıdır. Çok iyi iş gördüğüm bir yaklaşım bu. Gelen her hata için, hatayı gösteren otomatik bir birim dışı test oluşturun. "Ünite dışı" ile, sistemin birçok parçasına dokunabilen, veritabanı ve dosya sistemi vb. İsabet edebilecek bir şey kastediyorum - ama "otomatik" ile insan etkileşimi olmadan çalışır demek istiyorum. Bu, herhangi bir olayda regresyon paketinizde isteyeceğiniz test türüdür. Bunu yazmak çok şey başarır: bu çok kaba düzeyde bile kodu test edilebilir hale getirir ve sizi hata ile ilgili olabilecek bir kod takımyıldızına maruz bırakır, böylece sizi eğitir ve sizi bilgilendirir. çok özel olarak ilgili malzeme.

Ama bunun sonu değil. Bu test çalıştıktan ve kırmızı çalıştığında (koddaki hatayı gösterir), neyin yanlış olduğunu bulmak için zaman ayırın (bunu her durumda yapmanız gerekir). Ama henüz düzeltmeyin. Sorunun ne olduğunu düşündüğünüzü belirledikten sonra - bir birim yazınbu sorunu gösteren test. Şimdi üzerinde çalışabileceğiniz bir şey var (ve tesadüfen değil, daha fazla test edilebilirliğe doğru biraz daha fazla yeniden düzenleme yapmak zorunda kalmış olabilirsiniz). Hatayı düzeltin. Ünite test kartını izleyin. Belki bazı kenar durumlarda onu et; sağlam ve temiz ve iyi test edilmiş bir üniteyi - size sadece iki haftalık zamana mal olan - bir üniteyi alın. Şimdi regresyon testini çalıştırın ve geçtiğini izleyin (elbette, eğer değilse, daha fazla araştırma ve birim düzeyinde işiniz var - o da geçene kadar tekrarlayın). Hepsini kontrol et. Elinde ne var? Daha önce başarısız olan kod için regresyon testleri. Daha önce başarısız olan kod için birim testleri. Başarısız olan çalışma kodu. Daha iyi tasarlanmış kod, çünkü şimdi olduğundan daha test edilebilir. Kod tabanınıza daha iyi güven,

"Saf" TDD değil. Ancak sonuçları hızlı bir şekilde gösterir ve zamanla kodunuzun kalitesini artırır. Sonuçlar, yönetimin katılımını sağlamanıza yardımcı olacaktır.

Şirketimde, JoelOnSoftware'den "sadece bir homurdanma" yöntemiyle gittim ve normalde bir çeşit fırlatma konsolu uygulamasını bir araya getirdiğimde birim testleri yazmaya başladım. Daha kararlı sürümlerle işleri çok daha hızlı yapmaya başladım ve farkettim. Ne yaptığımı sorduğumda, eski kodu değiştirdiğimde ya da yeni bir kod yazdığım zaman TDD kullanmaya ve birim testleri yazmaya başladığımı açıkladım. Geliştiricilerim meraklanmaya başladılar ve entegre birim testlerini kendileri kullanmaya başladılar. Eski kod çalışması için testler yazmak için iyi bir argüman olduğunu düşünmüyorum, ancak otomatik testler yazmanın konsol kesmek spagetti yazmaktan daha hızlı ve daha kolay olduğunu söyleyebilirseniz, akıllı geliştiriciler takip edecek.Daha yüksek kaliteli yazılımlarla sonuçlanan diğer faydalar da orada olacak, ancak geliştiricinin oturum açmasının anahtarı, hayatlarını kolaylaştırdığını gösteriyor. İşe giriş olarak, daha iyi bir yazılımla sonuçlanacağı ve muhtemelen eskisinden daha az zaman alacağı gerçeği, onları ikna etmek için fazlasıyla yeterli olmalıdır.

Öncelikle, müşterinin parasına değer katmak için tutumunuz ve samimiyet anlayışınız takdir edilmelidir. İşte yöneticinizi ve müşterinizi nasıl ikna edebileceğinize dair düşüncelerim:

• Düzelttiğiniz hataların metriklerini son 6 aydır ve bir hatayı düzeltmeniz için gereken minimum, ortalama ve maksimum süreyi toplayın.
• Düzeltdiğiniz veya bağlamınız olan tüm hatalar için, bu alanları kapsayan birim testleri yazmayı deneyin.
• Üzerinde çalıştığınız hatalar ve üzerinde çalışacağınız hatalar için, herhangi bir değişiklik yapmadan önce bile bu alanlara birim testleri yazmayı deneyin. Ardından sebebini bulmak ve düzeltmek için kod yazın. Mevcut test durumunuzu ihlal edip etmediğine bakın. Cevabınız evet ise, akranlarınızın Birim Testlerinin önemini anlamalarına yardımcı olun.
• Tüm geliştiriciler Birim Testlerinin önemini anladıktan sonra, onlardan günlerce yaptıkları şeyi yapmaya devam etmelerini isteyin.
• Zaman ilerledikçe, ekiplerin üretkenliği hem yöneticinizin hem de müşterilerinizin verimlilik ve kod kalitesindeki iyileşme oranında şaşıracağı ölçüde gelişmelidir. Biraz zaman alıcı, ama denemeye değer.

Başka bir yol daha var ve bu, etrafta gerçekleşen Çevik Konferanslara katılmada yöneticinize katılmayı denemektir. Kesinlikle katılmaya değer.

Hiçbir şeyin işe yaramadığını düşünüyorsanız, devam edin ... size uygun yere katılın. Samimiyetle, ben de bunu yaptım. Her şey başarısız olduğunda, devam ettim;)

Ve kod yazdıktan sonra Ünite testlerinin ne olduğunu gerçekten TDD değil, ama bu her zaman ilk adım olabilir. En azından burada çok iyi uyuyor.

Size iyi şanslar ve başarılar diliyoruz!