İş arkadaşları birim testleri yazmak için nasıl motive edilir? [kapalı]

Yaklaşık 5 yıldır üretimde olan büyük bir ürün üzerinde çalışıyoruz. Kod temeli .. erm .. çalışıyor. Gerçekten iyi değil ama çalışıyor. Yeni özellikler üretime sokulur ve küçük bir KG ile test edilir. Hatalar vb. Düzeltildi. Ama benden başka kimse birim testleri yazmıyor. Hiç kimse, bu özel hatanın (test durumunun) bir daha asla yaşanmayacağından emin olmak için ünite testleri yazarak hataları takip etme gücünü kullanmaz.

Yönetimle konuştum. Geliştiricilerle konuştum. Şirketteki herkesle konuştum. Herkes şöyle der: "Evet, daha fazla birim testi yazmalıyız!" Bu yaklaşık bir yıl önceydi. O zamandan beri ön işleme kod incelemesi ( Gerrit ) ve sürekli entegrasyon ( Jenkins ) uygulamasına zorladım .

Birim testleri ile ilgili bazı toplantılar yaptım ve ayrıca birim testi yazmanın yararlarını da gösterdim. Fakat kimse ilgilenmiyor gibi gözükmüyor.

S1: Çalışma arkadaşlarımın birim sınamaları yazmalarını nasıl motive edebilirim?

S2: Kişisel kod kalite standartlarımı takip etme konusunda nasıl motive olurum? (Bazen gerçekten sinir bozucu!)

Not: Bazı sinir bozucu gerçekler (1 yılda ulaştı):

• Toplam birim testi: 1693
• Toplam "örnek birim testleri": yaklaşık 50
• Bana göre yapılır: 1521

Düzenleme: Çok mu bekliyordum? Bu benim ilk çalışma yerim ve elimden gelenin en iyisini yapmaya çalışıyorum.

Düzenleme 2: Tüm cevaplara dayanarak kendim için küçük bir kontrol listesi hazırladım. İki geliştiriciyle özel olarak konuştum ve iyi ve dürüst bir konuşma yaptık.

Onlardan biri, Telastyn'in dediği gibi , ünite testlerinden gerçekten rahatsız olduğunu söyledi. "Daha profesyonel olmak" istediğini söyledi ancak başlama vuruşuna ihtiyacı var. Ayrıca, tüm geliştiricilerle (yaklaşık 9-11 civarında) yapılan birim test toplantımızın iyi olduğunu, ancak çok kalabalık olduğunu söyledi. Meh. Benim için bazı eleştirmenler, ama bundan öğreneceğim. (tdd kata toplantıları için aşağıdaki cevaplara bakınız!)

Diğeri, birim testleri yazmakla ilgilenmediğini söyledi. Çalışmalarının maaşına yetecek kadar iyi olduğunu düşünüyor. Daha fazla çaba sarf etmek istemiyor. Ben tamamen suskuntum. Tipik 9-5 "işçi".

Gelecek hafta diğer geliştiricilerle konuşacağım.

Harika cevaplarınız (şimdiye kadar!) Ve desteğiniz için teşekkür ederiz. Gerçekten onu takdir ederim! Çok şey öğrendim, çok teşekkür ederim!

TDD hakkında konuşmanın pek işe yaramadığını fark ettim. İnsanlar ham sonuçları görmek ister . Söyleyen "yazma testleri geliştirme zamanı azaltacaktır" büyük olasılıkla doğrudur, ancak herkesin ikna almak için yeterli olmayabilir.

Benzer pozisyondaydım (sizinki kadar kötü değil) ve insanlar kodum üzerinde çalışmaya başladıklarında çözüldü (not: kodum ünite test edildi, diğerleri çok fazla değil). Bir şey çalışmayı bıraktığında, yerel soruşturmadan sonra doğal takip , neden ne olabileceğini sormaktı . Sonra oturduk, birim testleri yaptık ve ne olduğunu gördük. Testler geçiyorsa, çoğu zaman problemler yeni ve denenmemiş koddaydı. Olmazsa, testler genellikle sorunu tespit edebildi (ya da en azından bizi doğru yöne yönlendirdi). Hatayı düzelttik, testler tekrar başladı, herkes mutluydu.

Uzun lafın kısası, bunun gibi birkaç durum ortaya çıktı ve 2 geliştirici daha TDD / test meraklıları oldu (hala devam edecek birkaç şey var, ama umut verici görünüyor).

Tavsiye gelince, TDD kata ile gitmek; Hiçbir testin aksine bir test ilk yaklaşımını kullanarak uygulamak için basit bir görev . Görevin ne kadar karmaşık olduğuna bağlı olarak, test dışı yaklaşım yaklaşımı, özellikle artan gerekli değişikliklerle, genellikle daha yavaş olmalıdır:

• Roy'un dize hesap makinesi
• Banka OCR

Düzenleme : OP'nin yorumu bana emrinde daha güçlü bir tartışma olduğunu fark etti - regresyon aka dönen hatalar . Bu tür durumlar, ünite testlerinin ne kadar faydalı olabileceğini gösteren mükemmel örneklerdir. Rakamlar gibi insanlar - dediğim gibi, "birim sınamasının iyi olduğunu" söylemek ikna edici olmayabilir, ancak aşağıdaki gibi verileri düzenlemek kesinlikle olabilir:

• Özelliği uygulamak için harcanan zaman (testler yazılmadı; bunun sık sık olduğunu, bu nedenle bu tür bir örneği bulmak nispeten kolay olacağını düşünüyorum)
• TDD ile özelliğin uygulanması için tahmini süre (veya yaklaşımdan sonraki testler ; önemli değil - önemli olan ünite testlerinin varlığı)
• test edilmemiş kodla test edilmemiş koddaki hatayı çözmek için harcanan süre

Sizi uyarmak için bir şey (bu ortada açık ama dikkate değer): sonuç yanlılığı - sınama ile hata tespit etmenin tek yolunun o hata için test yazmak olduğu bir örnek seçmediğinizden emin olun. Genellikle, hiç kimse hatanın açık olacağını bilmez, ancak "X için test yaparsak bu hatanın önemsiz olduğunu söyleyince dostum" - bu bittikten sonra savaş için kazanan bir taktik bulmak kolaydır.

Eğer harcanan eğer - o örneklerin Sonuç basit bir soru olmalıdır , x-saat özelliği Y gelişmekte, neden bunu yapmakta ısrar ediyorum 2x ?

İlk önce neden test yazmadıklarını bilmelisiniz.

Sıkı dev programları sık sık sebep, ama sizde olmadığını söylüyorsunuz.

Bir sonraki sebep, mevcut test edilmemiş büyük bir kod tabanına sahip olmakla birlikte, yazma testleri muhtemelen çok zor görünüyor - hiç bitmeyen bir iş (çamaşırhane ve heyecan verici gibi). Yani insan doğası bunun yüzleşmek için çok fazla olduğunu düşünmektir, bu yüzden atlayacağım.

Başka bir neden, testlerin iyi bir fikir olduğunu düşünürken, özellikle onları yazacak hiçbir yerde çalışmamışlarsa, onları yazmaya nasıl başlayacağından emin olmadıkları olabilir.

Bir diğer güçlü olasılık da, fikre dudaklı hizmet veriyor olsalar bile, daha fazla iş için hiçbir değer görmüyor olmalarıdır.

Peki, farklı nedenlerle nasıl başa çıkıyorsunuz?

Sebep bir basittir, onlara geliştirme zamanından nasıl tasarruf edildiğine bir örnek gösterin.

İkinci neden - onlara bir yılda kaç test yazdığınızı ve kod tabanının yüzde kaçını kapsadığını gösterin. Gelecek yıl bu saatte yapabilecekleri daha fazla test yapabileceklerini göstermek için matematiği yapın. Günlük bazda küçük ilerleme parçalarının gerçekten toplandığını gördüklerinde, bütün fikir çok zor değil. Verileri sistemden çekebiliyorsanız, kodun denenmemiş bölümlerinde kaç hata olduğunu, hataların birim testlerinde kaç tane hata olduğunu görün.

Sebep 3 sadece gösterme değil, eğitimdir. Onları bir eğitim sınıfında test yazmalarını sağlayın.

Sebep 4, bu konunun özüdür. İlk önce, birçok kez geri dönen böceklerden bir acı noktası seçin. Bu gerçekleştiğinde, yönetime bu maddede birim testleri yaptırmaları halinde kötü bir kuruş gibi geri gelmeyeceğini önerme zamanıdır.

Sebep 4'ü ele almanın bir başka yolu da yönetimin sürecin bir parçası olmasını sağlamaktır ve testler de kod incelemesini geçmedikçe kod kod incelemesini geçemez. Bu acı noktalarından birinden hemen sonra veya tercihen birkaç gün içinde birkaç gün geçirdikten hemen sonra bir politika yaparak onlara yaklaşmak en iyisidir.

Hepimiz geliştiriciler olarak kendimizi yönettiğimizi (LOL) düşünmek isteriz, ancak hırslılar yönetimin kendileri için neye dikkat etmesi gerektiğini ve gerçekten kendi kendini yöneten profesyonellerin zaten testleri yazdıklarını önemser. Ürünü geliştirdiği için profesyonelliği ve en iyi uygulamaları yapmayı umursamıyorlarsa ya da yöneticileri terfi ettirmeyi (veya kovulmamasını) etkilemeyi umursuyorlarsa, bunun sizin için doğru yer olup olmadığını düşünebilirsiniz. En iyi uygulamaları önemsemek için yönetim bulamazsanız, o zaman her zaman bir yokuş yukarı savaşa gireceksiniz ve bunun sizin için doğru kurum kültürü olup olmadığını değerlendirebilirsiniz. Her işyerinin kendi sorunları vardır (ve kaçmak her zaman cevap değildir), burası profesyonelliğinize uygun görünmüyor.

Ben ediyorum başlamak TDD faydalarını göstererek. Birim testinin faydalarını sergilemeye çalışın.

Normal insanlar olarak, geliştiriciler faydalarla motive edilir. Daha fazla iş yaratan şeyler yapmak istemiyorlar. Birim testi daha az iş demektir . Arkadaşlarla daha fazla dışarı çıkmak demek. Daha fazla eğlenmek demek, çünkü her gece saat 11: 00'e kadar kodlama yapmak zorunda değilsiniz. İçiniz rahat olsun diye tatile gitmek demektir.

TDD'nin en büyük yararlarından biri , programınızı daha iyi bir tasarıma yeniden düzenleyebilmeniz veya bir şeyin adını değiştirebilmenizdir. hiçbir şey kırmadı.

TDD için bir başka büyük durum , eski kod için birim testleri oluşturmaktır . Bu, kötülüğü yeniden düzenlemeye başlamanın en iyi yollarından birini temsil eder. Uzun vadede, kod bazındaki bilgilerinizi geliştirmek, güçlü yanlarını ve kusurlarını anlamak, kodda kodlanmış iş mantığını tespit etmek ve kaliteyi ilerletmek için iyi bir başlangıç ​​yapmanızı sağlayacak!

Daha fazla okuma için iyi referanslar:

• Neden Birim Testleri Yazmalısınız?
• Motivasyon Görünürlüğü ve Birim Testi
• Roy Osherove'ye göre birim testi sanatı

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Sanırım bir süre önce bir Jeff Atwood makalesinden bu bağlantıyı işaretledim [değiştir: yep, işte burada] . Eski ama alakalı. Bu faydalar ve şüphesiz diğer cevaplarda ana hatlarıyla belirtilecek olan diğerleri nedeniyle, programcılarınızın kendilerini motive edebilmeleri gerekir ! Daha verimli çalışmalarını sağlayacak ve böylece işlerini biraz daha kolaylaştıracak. Bunu kim istemiyor?

2. sorunuzla ilgili olarak: kodlama kalite standartlarınızdaki sahiplik ve gurur duygunuz, onlarla devam etmenizi sağlar . Bu standartlara göre neyi başarmak istediğinizi ve bunlardan kimlerin faydalanabileceğini düşünün. Kişisel kod standartlarım da sinir bozucu olabilir, ancak her zaman dünyayı / şirketi / takımı uygulayarak bir iyilik yaptığımı hissediyorum. Bu yüzden çok fazla şey yapmaya çalıştığınızı sanmıyorum - sonuçlar yerlere göre değişebilir, ancak en azından çaba göstereceksiniz.

Bu örnek olarak büyük bir liderlik durumu gibi görünüyor .

Mücadele ettiğiniz insan doğasının iki doğal yönü var:

• Yaratıcı insanlar süreci sevmez.
• Çoğu insan, kalitesi hakkında dışsal olumsuz kararlardan hoşlanmaz.

Bununla ders anlatımı, yönetim bildirimleri ve hatta mantıkla mücadele etmek çok zordur. İnsan doğasının alternatif bir yönünden yararlanarak kazanmak zorundasınız.

• İnsanlar en iyi çalışanların davranışlarını taklit eder

En iyi çalışanlar TDD kullanıyorsa ve çalışırsa, süreç genişleyecektir. Olmazlarsa, olmaz. Birini ikna etmeniz gerekiyorsa, en iyi 1 veya 2 çalışandır.

Onlara sor.

İnsanlara söylendiğini söylüyorsunuz ve daha fazla test yazmaları gerektiği konusunda hemfikirsiniz. Neden değiller?

Basit bir motivasyon meselesi olmayabilir (çoğu zaman olmaz). Onlar hakkında unutabilirler. Zaman baskısı altında hissedebilirler. İyi testler nasıl yazılacağını bilemeyebilirler. Bunu yapmana gerek kalmayacak kadar iyi olduğunu düşünebilirler. Kök nedenini bilmek, sorunu daha iyi çözmenize yardımcı olacaktır.

Birim testlerinin kendileri satış olacağını düşünürdünüz. Firmanızın nasıl çalıştığını bilmiyorum, ancak üretim sırasında bir sorun olduğunda, düzeltilene kadar çalışırız. Pazar sabahı saat 2'de olup olmaması önemli değil. Bu bizim için çok nadir görülür, fakat öyle olduğunda berbattır.

Onlara, otomatik testlerde kolayca bulunabilecek bazı önemli sorunları çözmek için gecenin ortasında kaç kez kalkmaları gerektiğini sorarak başlardım. Bu otomatik testin her şeyi çözeceğini söylemek değildir, ancak bunu azaltmaya yardımcı olması gerekir.

İkinci büyük satıcı ise KG devridir. Şirketimde TDD'nin başlamasından önce, her hafta test etmek için yeni sürümleri KG'ye gönderirdik. Bu sürümden bir yığın hata yaratacaklardı, bu böcekleri düzeltir ve başka bir sürümü serbest bırakırız. Tamamlanana kadar tekrarlayın. TDD'yi yaptığımız ilk projede birkaç hafta sonrasına kadar KG'ye bir itiraz gerekmedi. Ve bulunan böceklerin sayısı çok, çok küçüktü. Benzer bir projeye göre% 10. Takımınız için bu istatistikleri derlemeye zaten sahip misiniz?

Diğer büyük satış noktası, TDD'nin benimsenmesinden sonra kodun nasıl göründüğü idi, okuması kolaydı, çünkü test etmeyi kolaylaştırmak istedik. Birim testleri için yazılan kod ile yazılmayan kod arasında bir karşılaştırma gösterin.

Son olarak, onlara kodları nasıl güvenle yeniden aktarabileceklerini göster.

Test yazmak istemiyorsanız, bunları aklınızda bulundurun. :)

HLGEM'in cevabını genişletmek istiyorum , özellikle bu bölüm:

Bir sonraki sebep, mevcut test edilmemiş büyük bir kod tabanına sahip olmakla birlikte, yazma testleri muhtemelen çok zor görünüyor - hiç bitmeyen bir iş (çamaşırhane ve heyecan verici gibi). Yani insan doğası bunun yüzleşmek için çok fazla olduğunu düşünmektir, bu yüzden atlayacağım.

Ben yazmak kodu tespit ettik yazma testlerinde niyetiyle ben yazma testlerinin niyeti olmadan yazma kodu önemli ölçüde daha iyi kodudur; kendime sorarak bu fonksiyonu nasıl test edeceğim? her işlevin daha iyi bir tasarımını zorlar. (Global veya yarı global verilere daha az güveniyor; IO hesaplamadan ayrıldı; işlevler yalnızca tek bir şey yapıyor; tutarlı hata işleme ve benzeri).

Testler akılda tutulmadan eski kodlara yapılmaya çalışılmalıdır.

Birkaç teknik kullandım:

a) otomatik bir yapı kurmak. Birisi test ettiğiniz bir şeyi kırdığında, testin nasıl algıladığını ve hatanın ne kadar kötü olacağını gösterin.

b) Testlerle karmaşık projeler yapın (sürün). Bu, o projede kaç tane böcek bulunduğunu gösterecektir. Kusursuz çalışmaya başlayan bir karmaşık sunucu etkileşimi projem vardı. QA'da hiçbir zaman başarısız olmadı ve tüm entegrasyon testleri% 100 sorunsuz geçti. Bu sistem son derece kararlı olarak bilinir hale geldi ve genel yönetim bundan memnun oldu. Bu durumlarda ne yaptığınız, birim testinin bunu nasıl sağladığını gösterir.

c) Bir seferde bir kişiyi çekin. Seni dinleyen kişi. Böcekleri ele alın ve testlerin nasıl derin ve zor problemleri ortaya çıkardığını gösterin. Bu yardımcı olur. Asla kolay bir şey değil. Ama bir hayranını bulduktan sonra, sadece yardım edecek. Bu bir domino etkisi.

İşlemde fırında birim testi. Üretimde bir böcek birim testinde yakalanamayacak kadar açıksa, bu adam suçu üstlenir. İnsanları yaptıkları her testi yazmaya atayın. Rasgele vakaları seç ve her hafta birkaç vakanın yürütülmesini izle. Birim testleri yaparak, insanlar gereksinimler hakkında sorular soracak ve nihayetinde hem gerekli hem de işe yarayan yazılımlar geliştirmek ve umarım geliştirmek için gereksinimleri bağlayacak :)