Metodoloji: Başka bir geliştirici için birim testleri yazma

Yazılım geliştirme ve birim testleri yazma hakkında düşünüyordum. Aşağıdaki fikri anladım:

Bir çift geliştiricimiz olduğunu varsayalım. Her çift kodun bir kısmından sorumludur. Çiftin bir özelliği bir özellik uygular (kod yazıyor) ve ikincisi bunun için bir birim test yazıyor. Testler koddan sonra yazılır. Benim fikrimce birbirlerine yardım ediyorlar, fakat ayrı ayrı çalışıyorlar. İdeal olarak, iki benzer boyutta özellik üzerinde çalışacak ve daha sonra test hazırlığı için değişim yapacaklardır.

Bu fikrin bazı yönleri olduğunu düşünüyorum:

• Testler, uygulama hakkında daha fazla şey görebilen biri tarafından yazılır,
• çalışma, çift programlamaya göre biraz daha hızlı yapılmalıdır (aynı anda iki özellik),
• Hem testlerin hem de kodların sorumlusu vardır,
• kod en az iki kişi tarafından test edilir ve
• belki de kodunuzu test eden kişi tarafından yazılan koddaki hataları aramak daha iyi kod yazmak ve köşeleri kesmekten kaçınmak için özel bir motivasyon sağlayacaktır.

Belki de kod ve test geliştirme arasında kod incelemesi için başka bir geliştirici eklemek iyi bir fikirdir.

Bu fikrin dezavantajları nelerdir? Zaten bilinmeyen bir metodoloji olarak tanımlanmış ve yazılım geliştirmede kullanılmış mı?

PS. Profesyonel bir proje yöneticisi değilim, ancak proje geliştirme süreçleri hakkında bir şeyler biliyorum ve en popüler birkaç metodolojiyi biliyorum - ama bu fikir bana tanıdık gelmiyor.

Üretim kodunu yazma ve ilgili birim testlerini yazma çabasını bölmek için çift kullanmanın genel yaklaşımı nadir değildir. Şahsen daha önce iyi bir başarı ile bu şekilde eşleştirilmiş bile oldum. Ancak, üretim kodunu yazan kişi ile test kodunu yazan kişi arasındaki kesin bir çizgi mutlaka sonuç vermeyebilir.

Benzer bir yaklaşım kullandığımda, çift konuşarak ve sorunu ortak bir şekilde anlatarak başlıyor. TDD kullanıyorsanız, önce bazı temel testlerle başlayabilirsiniz. TDD kullanmıyorsanız, belki de yöntem tanımıyla başlayabilirsiniz. Buradan sonra, her iki taraf da hem üretim kodunda hem de test kodunda çalışır, bir kişi her bir konuya odaklanır, ancak üretim kodunu ve bunun arkasındaki test kodunu geliştirme yollarından bahseder.

Her çifte iki özellik vermenin avantajını görmüyorum. Elde edeceğiniz şey, bazı özellikler için TDD'ye benzeyen ve diğer özellikler için olmayan bir şeydir. Odağını kaybedersin. Gerçek zamanlı meslektaş değerlendirmesinden faydalanmıyorsunuz. Eşleştirmenin önemli yararlarından hiçbirini alamazsınız.

Çift programlama uygulaması hız ile ilgili değil, kalite ile de ilgilidir. Dolayısıyla daha hızlı ilerleyerek yönlendirilen modifiye bir tekniği kullanmaya çalışmak doğaya aykırıdır. Paralel kod gözden geçirme ve test geliştirme yoluyla daha kaliteli yazılımlar oluşturarak, her bir değişiklikten en az iki kişi bulunduğundan ve akran incelemesi ve testi için bekleme döngüsünü ortadan kaldırdığınız (veya azalttığınız) olduğundan aşağı yönde zamandan tasarruf edersiniz.

Fikrinizdeki asıl sorun, herhangi bir kod için yalnızca test yazamamanızdır. Kod test edilebilir olmalıdır.

Yani, alaycı enjekte edebilmeniz, test etmek istediğiniz bitleri ayırmanız, değiştirilen ve onaylamanız gereken erişim durumu vb.

Şansınız ya da testi ilk defa yazmazsanız, olasılıklar testi biraz kodla yeniden yazmak demektir. Hangi, ilk önce kodu yazan kişi değilseniz, gecikme, toplantılar, yeniden düzenleme vb.

Burada gördüğüm asıl konu, birim seviyesinde, kod yazarken derlemek, çalıştırmak ve en belirgin hataları derhal silmek istiyorum - kod eksik olduğunda ve birim, özellik veya işlevi bildiğimde sadece kısmen uygulandı. Birimin kodunu çalıştırmak için, uygulamayı çağıran bir program parçasına, genellikle bir birim testine veya en azından kısmi birim testine ihtiyacım var. Bu mutlaka "Kitabın TDD stili" değildir, böyle bir test, test edilen koddan önce veya sonra yazılabilir.

Ünitemin bir sürümü "özellik tamamlandı" ve tüm hatalardan arınmışsa, bu şekilde kendi başıma bulabilirim, o zaman ikinci bir kişiye devretmek ve ek ünite testleri yazmasına veya kodumu incelemesine izin vermek mantıklı olur. . Ancak bana göre, derleyici hiçbir uyarı göstermediğinde onu teslim etmenin bir anlamı yoktur, test cihazını "henüz" işe yaramayan ya da çalışacak şeyleri ayrıntılı olarak açıklamak zorunda kaldığımı bilmem durumunda kesinlikle çok erken iki saat içinde farklı olarak hala bu kod parçası üzerinde çalışıyorum. Bu detay düzeyinde bunun için gerekli olan genel iletişim IMHO'nun faydalarla dengelenmemesini sağlayacaktır.

Bu yüzden evet, ikinci bir donanım ek ünite testi yazma zorunluluğu var, ancak ünite testlerini özel olarak yazmak için değil .

Aşağıdaki durumlardan herhangi birinin meydana gelme olasılığı var gibi görünüyor - bunların tümü istenmeyen:

karışıklık

Ewan'ın belirttiği gibi, CUT'nin test edilebilir hale getirmek için değişmesi gerekebilir. Değişimin nedeni, geliştirici tarafından her zaman açık değildir (ve anlaşmazlıklara neden olabilir).

çekişme

A Geliştirici kodunu tamamlamış ve test etmesini isteyebilir. B geliştiricisi de gelişiyor olabilir ve bu nedenle birim testlerine katılmak için kodlarını park etmek konusunda çekingen olabilir.

İçerik değişimi

Bile geliştirici B tarafından yazılan kodu test etmek onların gelişimini rafa kaldırmaya istekli olduğunu geliştirici A - aktivitesinde değişim ücrete tabidir.

Bu edilmiş yıllardır kabul adam gücünü iki katına geliştirme zamanı yarıya gelmez. Yukarıda ana hatlarıyla belirttiğim faktörler göz önüne alındığında, bu düzenlemenin işleri nasıl iyileştireceğini görmek zor.

Çift programlama ve TDD ile birlikte kullanıldığında , buna Ping Pong Kalıbı denir :

• Bir yeni test yazar ve başarısız olduğunu görür.
• B testi geçmek için gereken kodu uygular.
• B, bir sonraki testi yazar ve başarısız olduğunu görür.
• Testten geçmek için gereken kodu uygular.

Ve bunun gibi. Yeniden sürüş, araç kullanan kişi tarafından ihtiyaç duyulduğunda yapılır.

Ancak her iki programcının da farklı bilgisayarlarla kodlanmasını öneriyor gibi görünüyorsunuz. Ayrı ayrı yapmak, çok düşük bir seviye şartnameye sahip olmayı gerektirir. Bu çevik metodolojilere aykırıdır. Her değişikliğin koordine edilmesi gerekir. TDD'de anında düşük seviyeli tasarım yapıyorsunuz ve bu bir sorun değil. Yaklaşımınızın önceden kodlanmış bir çeşit iskelet sahibi olmasını gerektirdiğini farz ediyorum.

Her neyse:% 100 verimli olmasa bile, yeni şeyler yapmanın yöntemlerini test ederek çok şey öğrenebilirsiniz. Test edebilir ve gerçek yaşam deneyiminizi paylaşabilirsiniz

Bu partiye geç geleceğim, ama ekleyecek bir şeyim olduğunu düşünüyorum.

Zaten bilinmeyen bir metodoloji olarak tanımlanmış ve yazılım geliştirmede kullanılmış mı?

Eş Testi'ni açıklıyorsunuz .

Bir çift geliştiricimiz olduğunu varsayalım.

Ah, iyi bir çift ​​programlama .

Her çift kodun bir kısmından sorumludur. Çiftin bir özelliği bir özellik uygular (kod yazıyor) ve ikincisi bunun için bir birim test yazıyor. Testler koddan sonra yazılır. Benim fikrimce birbirlerine yardım ediyorlar, fakat ayrı ayrı çalışıyorlar.

Bu Çift Programlama değil.

İdeal olarak, iki benzer boyutta özellik üzerinde çalışacak ve daha sonra test hazırlığı için değişim yapacaklardır.

Bu kesinlikle Akran Testi. İşte bunun hakkında bir ACM kağıdı . Bunu yaptım. Akran Değerlendirmesi sürecinin resmi bir parçası olduğu yerde çalıştım . Yararlı, ancak kesinlikle ilk test satırı olması amaçlanmadı ve kesinlikle klasik Çift Programlama değil.

Bunun için başka bir isim Whitebox Testi . Her ne kadar bu tanım, test edenlerin, test edenlerin test ettikleri şeyin iç işlerini görebildikleri gerçeği ile ilgisi olmasa da, Blackbox testinin tersine, sadece girdiklerini ve Neler çıkıyor? Kara kutu tipik olarak KG'nin yaptığı şeydir.

İlk test satırı kodlayıcıya sıkıca dayanıyor. Bilmiyorsanız, kodumu kendim test etmememi istemiyorsanız, açıkça yapmayı reddettiğim. Kodumu 10 yaşımdan beri test ediyorum. O zamanlar süslü ünite testleriyle test etmemiş olabilirim ama kodum test edildi. Her koştuğumda test edildi.

Bir akran test cihazından beklediğim, testime ekleyen testler. Hakem, kodun gözden geçirdiği sırada kodda bulduğu sorunları açıkça ortaya koyan testler. Bu sorunları otomatik bir testle ifade etmek, ne anlama geldiklerini daha kolay anlamanızı sağlar. Etkileyici, aklımda olan ve henüz konuştuğum noktayı göremeyen akranlar ile teknik konuşmalar yaptım ve sonra onlara problemi göstermenin en iyi yolunun bir birim testi yazmak olduğunu anladım. Bu Akran Testi.

Şimdi bana kodumu yazmadan önce bana yazılı sınavlar vermek istersen. Bir gereklilik belgesini derleyecek kadar resmi değildir.

DDT (geliştirme odaklı test, koddan sonra aka testler), çift programlama ve birkaç yıl boyunca kırmızı-yeşil-refactor TDD yaptım. İddialarınıza nokta noktayla cevap vermek için:

Testler, uygulama hakkında daha fazla görebilen biri tarafından yazılır.

Testleri yazan kişinin, uygulamayı aşırı yakından tanımadan, kapsamı iyi olan testleri yazmak için uygulamayı mümkün olduğunca yakından bilmesi gerekir . Bunun klasik örneği, ikisi ne test etmeye çalıştığınızı kanıtladığında üç girdiyle test etmektir. Okuduktan sonra kodu aşina olmalarına rağmen, orijinal geliştiricinin şu anki duruma ulaşmak için neler yaşadığını tam olarak anlayamayacaklar. Bu nedenle, kodu optimalden daha az anlayacaklardır.

çalışma, çift programlamaya göre biraz daha hızlı yapılmalıdır (aynı anda iki özellik).

Bunu neden söylediğini anlamıyorum. Birisi test yazarken yeni özellikler üzerinde çalışmıyorlar. İki farklı çalışma türü vererek birinin çalışma kapasitesini sihirli bir şekilde iki katına çıkaramazsınız. Tecrübelerime göre yazma testleri genellikle üretim kodu yazmaktan daha zordur , bu nedenle kesinlikle başka bir özellik yazarken bazı kodlar için üretken ve sorumlu bir şekilde testler yapamazsınız.

Hem testlerin hem de kodların sorumlusu vardır.

İlk olarak, testler şunlardır kodu. İşe yönelik test kodu neredeyse üretim kodu kadar önemlidir, çünkü işletmenin yazılımı korkusuzca değiştirmesini sağlar . İkincisi, bu testler ve üretim kodunu yazan bir kişiden, hatta her ikisini birden yazmadan farklı değildir.

kod en az iki kişi tarafından test edilir

Hayır, sadece testi yazan kişi tarafından test edilir. Test için daha fazla zaman kullanmak istemiyorsanız, neden bu durumda ikide durmalısınız?

belki de kodunuzu test eden kişi tarafından yazılan koddaki hataları aramak daha iyi kod yazmak ve köşeleri kesmekten kaçınmak için özel bir motivasyon sağlayacaktır.

Geliştiriciler (hatta kıdemli olanlar) “iyi” kodun ne olduğu konusunda çok farklı fikirlere sahiptir. Bir kişinin köşe kesmesi, bir başkasının en kısa sürede ASAP çalışma koduna geçmenin mükemmel bir yoludur. Bu suçlama ve sistemi oyun için bir reçetedir.

Kırmızı-yeşil-refactor TDD ( aslında , başarısız görerek, onu çalıştıran, üretim kod yazmak üretim kodu değiştirmeden önce tek testi yazma sadece o başarılı görünce tekrar testi çalıştıran ve daha sonra üstlenmeden ve atlama değil ya herhangi takas Bu adımlar) ve kod incelemeleri çalışması.

Bu fikrin bazı yönleri olduğunu düşünüyorum:

Le'ler teker teker geçiyorlar.

Testler, uygulama hakkında daha fazla şey görebilen biri tarafından yazılır,

Yani, ilk geliştiricinin, işe yaramayacağından emin olduğu bazı uygulamaları yazmak için zaman harcadığını söylüyorsunuz. Ardından, başka bir geliştirici gelir ve testler yazar, koduna dayanarak mantığını temel alarak kimse doğru olup olmadığını bilmiyor ve sadece kodun ne yapması gerektiğine ilişkin test yazma ile karşılaştırıldığında taktiksel bir avantaj getireceğini umuyorum. Eğer uygulama yanlışsa, yazım sınavlarına yönelik sıfır yardım getireceği kanısındayım.

çalışma, çift programlamaya göre biraz daha hızlı yapılmalıdır (aynı anda iki özellik).

Her iki geliştirici de ilk geliştirmelerini tamamladığında, kodlarından birinin doğru olup olmadığını kimse bilmiyor. Bu hala kontrol altında kalmaya devam ediyor, hiç kimse yapılanları işaretleyemiyor ve ne zaman yapılacaklarını tahmin edemiyor. Bunu TDD ile karşılaştırın: Önce testi yazın, sonra testi başarısız yapın, sonra kodu girin. Bu daha fazla senaryoyu destekleyen koddur. Bu ileri hareket.

Bunları paralel olarak ilerletirseniz, her iki özellikte de yeniden kullanılabilecek kod iki kez yazılacak ve iki kez daha pahalı olacaktır.

Hem testlerin hem de kodların sorumlusu vardır,

XP tarafından önerilen şekilde kolektif kod sahipliğine bakın. Koddan sorumlu daha fazla kişiye sahip olacaksınız. Amacınız geliştiriciler arasında bilgi paylaşmaksa, neden onları ayırmaya çalışıyorsunuz?

kod en az iki kişi tarafından test edilir

TDD çifti ile de. Eşleştirme yaparken, her iki kişi de yazılı kodun yeterli olduğuna veya yazmamasına karar vermelidir. Bu bir kavgaya yol açarsa, takımdaki bazı insanların yanlış yerleştirilmiş ego problemi vardır.

belki de kodunuzu test eden kişi tarafından yazılan koddaki hataları aramak daha iyi kod yazmak ve köşeleri kesmekten kaçınmak için özel bir motivasyon sağlayacaktır.

Hataları aramak, bir noktada içeri girmelerine izin verdiğinizi ima ediyor. Girdilerse fark edilmediler. Öncelikle test yazmayı reddetmek, girmeleri gereken hatalara lisans veriyor.

Kesme köşesi istenmeden olabilir. Çift programlama bunun için var. Çiftin her üyesine diğerinin köşelerini kesmesine izin vermeme talimatı verilmelidir, çünkü bunu hepimiz yapıyoruz. Gururunu dolaba bırakıp, ofisten çıkarken geri almanı gerektirir. İnsanlarınızın haksız yere titiz olmalarını beklerseniz, genel durumu düşünmez ve başarısızlığa kendinizi hazırlarsınız.

XP açıkça tüm uygulamaların birbirlerinin kusurlarını gidererek birbirlerini güçlendirmek için yapıldığını söylüyor. Diğerlerinden ayrılmış herhangi bir XP uygulamasının eleştirisini dinlememelisiniz. Hiç kimse pratik mükemmel değildir, TDD mükemmel değildir, çift programlama mükemmel değildir, toplu kod sahipliği mükemmel değildir ancak hepsi birbirini kapsar.