TDD ve Sürüm Kontrolü

Şu anda TDD'yi öğreniyorum ve kişisel projelerimde uygulamaya koymaya çalışıyorum. Ayrıca bu projelerin çoğunda sürüm kontrolünü yaygın olarak kullandım. Bu iki aracın tipik bir iş akışındaki etkileşimi ile ilgileniyorum, özellikle de işleri küçük tutmak için en fazla söz konusu olduğunda. İşte akla gelen bazı örnekler:

1. Yeni bir projeye başladım ve henüz varolmayan bir sınıf oluşturmak için basit bir test yazıyorum. Test derlemese bile, dersi yazmadan önce testi yapmalı mıyım? Yoksa test yapmadan önce testin derlenmesini sağlamak için gereken minimum miktarda kodu saptayım mı?

2. Bir hata bulup yeniden oluşturmak için bir test yazarım. Başarısız olan testi yapmalı mıyım veya hata düzeltmeyi uygulamalı mıyım ve sonra yapmalı mıyım?

Bunlar hemen akla gelen iki örnektir. Cevabınıza ek örnekler vermekten çekinmeyin.

Düzenle:

Her iki örnekte de, testi yazdıktan hemen sonra testi geçmek için kod yazacağımı varsaydım. Başka bir durum da ortaya çıkabilir: TDD kullanarak birkaç saat taahhütte bulunmadan bir proje üzerinde çalışıyorum. Sonunda taahhütte bulunduğumda işimi küçük parçalara bölmek istiyorum. (Git, değişikliklerin sadece bir kısmını tek bir dosyada yapmak istese bile, bunu nispeten kolaylaştırır.)

Bu, sorumun ne zaman ne kadar kararlı olacağına dair ne kadar kararlı olduğum anlamına geliyor .

Test derlemese bile, dersi yazmadan önce testi yapmalı mıyım? Yoksa test yapmadan önce testin derlenmesini sağlamak için gereken minimum miktarda kodu saptayım mı?

Tabii ki değil. Hem testi hem de sınıfı bitirmelisin. Derleme bile yapılmayan bir şeyi ¹ yapmak hiç mantıklı gelmiyor ve düzenli olarak yaparsanız kesinlikle aynı proje üzerinde çalışan insanları sinirlendirecek.

Bir hata bulup yeniden oluşturmak için bir test yazarım. Başarısız olan testi yapmalı mıyım veya hata düzeltmeyi uygulamalı mıyım ve sonra yapmalı mıyım?

Hayır, başarısız bir test yapmayın. LeBlanc Yasası şunları belirtir:

Daha sonra asla eşittir.

ve testiniz uzun süre başarısız olabilir. Sorunu algılanır algılanmaz düzeltmek daha iyidir.

Ayrıca, TDD geliştirme stili şunları söylüyor:

Test odaklı geliştirme, başarısız olan test senaryolarını ekleme, onlardan geçme ve yeniden düzenleme adımlarını sürekli tekrarlar.

Başarısız bir testten geçerseniz, çevrimi tamamlamadığınız anlamına gelir.

¹ Karar verdiğimde, gerçekten bagaja bağlanmayı kastetmiştim (git kullanıcıları için değişikliklerinizi zorlayın, böylece diğer geliştiriciler onları alabilsin).

Test derlemese bile, dersi yazmadan önce testi yapmalı mıyım?

Yok hayır.

Başarısız testi yapmalı mıyım?

Yok hayır.

Burada iki paradigmadan bahsediyorsun:

1. Teste dayalı geliştirme - kod işleme hakkında hiçbir şey söylemez. Gerçekten, size kodun nasıl yazılacağını ve ne zaman yapıldığını anlatır. Bu yüzden her "yapılan" bir taahhüt için bir aday olarak düşünürdüm.
2. Çevik gelişme, özellikle: "erken ve sık taahhüt" (TDD gerektirmeyen). Bunun arkasındaki fikir, sistemdeki diğer bileşenlerle erken bir entegrasyona sahip olmak ve böylece erken geri bildirim almak. Yerel olarak bir DVCS'ye giriş yaparsanız ve itmeyin, bu anlamda değersizdir. Yerel taahhütler, geliştiricilerin yalnızca çalışmalarını yapılandırmasına yardımcı olur.

Tavsiyem: kodunuz derleninceye kadar TDD döngüsünü takip edin, testleriniz yeşil renkte ve sisteme katkıda bulunacak bir şeyiniz var. Bu nedenle, özelliklerinizi dikey olarak kesmelisiniz, örneğin, yeni bir UI maskesi için tüm formu oluşturmaz ve iş mantığı olmadan işlem yapmaz, daha ziyade küçük bir yönü uygular, ancak ön uçta ve iş mantığının yanı sıra kalıcılık katmanında .

Büyük bir hata düzeltmesi için, hata henüz düzeltilmemiş olsa bile, her geliştirmeden sonra (örneğin yeniden düzenleme) taahhütte bulunun. Testler yeşil olmalı ve yine de kod derlenmelidir.

Kesinlikle git gibi sağlıklı bir kaynak kontrolü kullanmaya başladınız.

O zaman istediğiniz şekilde çalışabilir ve her köşede karar verebilirsiniz - herhangi bir adım veya alt adım adil bir oyundur.

Sonra işleri zorlamadan önce tüm işi ezip geçiyorsun. Ya da bir çift, her şeyin yeşil olduğu ve kompozisyonun anlamlı olduğu noktalarda. Ve bu mantıklı taahhütleri zorla. Birden fazla durumda, --no-ff ile birleştirdiğiniz bir dal yapın.

Kaynak kontrolü, bir iş takip sistemi veya tarihçi değildir. Taahhütler makul bir tutarlı delta sunarken, ödeme durumu en azından derlenir. Ara ürünler gözden geçirme amacıyla bir süre korunabilir, ancak her şey yolunda kabul edildiğinde, özellik başına tek bir taahhüt adil olur.

Benim dünyaya, benim için geri dönüşün istenebileceği bir noktaya karar vermeyi taahhüt ettiğimi anladım. Testin başarısız olduğu (ancak derlendiği) kesinlikle böyle bir noktadır. Test geçişi yapmaya çalışırken yanlış yöne doğru dolaşırsam, kodu tekrar başlangıç ​​noktasına geri döndürmek ve tekrar denemek isterdim; Eğer taahhüt etmediysem bunu yapamam.

Test derlemese bile, dersi yazmadan önce testi yapmalı mıyım?

Bir dallanma SCM'sinde (Git'i kullandığınızı gördüm) bir yedekleme noktası istediğiniz zaman ("bir şeyi mahvettim; çalışma dizinini en son yedekleme noktasına sıfırlayacağım") veya kararlı bir sürümünüz olduğunda işlem yapmalısınız. Sabit bir sürüme sahipseniz (tüm testler geçiyorsa), mevcut özellik kolunu ana geliştirme kolunuzla birleştirmeyi de düşünmelisiniz.

Yoksa test yapmadan önce testin derlenmesini sağlamak için gereken minimum miktarda kodu saptayım mı?

Size bağlı (git, ekibinizin diğer üyelerini etkilemeden istediğiniz zaman veya farklı özellikler üzerinde çalışma yeteneğiniz olmadan, istediğiniz zaman taahhütte bulunma esnekliği sağlar). Sadece aynı dalda aynı anda birden fazla eksik (çalışma dışı) özelliğin olmadığından emin olun (daha sonra birbirlerini engellerler).

Bir hata bulup yeniden oluşturmak için bir test yazarım. Başarısız olan testi yapmalı mıyım veya hata düzeltmeyi uygulamalı mıyım ve sonra yapmalı mıyım?

Test kodu gerçekten küçük / önemsiz olmadıkça, genellikle iki taahhütte bulunurum.

Bunlar hemen akla gelen iki örnektir. Cevabınıza ek örnekler vermekten çekinmeyin.

Düzenle:

Her iki örnekte de testi yazdıktan hemen sonra testin geçmesi için kod yazacağımı varsaydım.

Bu yapmak için yanlış bir varsayım olabilir. Yalnız çalışıyorsanız (kişisel proje) hiçbir şey sizi sürekli yapmaz. En başarılı projelerimden birinde (projenin geliştirilmesi boyunca yüksek kod kalitesini ve TDD'yi korumakla ilgili olarak), uygulamadan birkaç hafta önce testleri tanımladık (yani, "" test_FOO_with_null_first_parameter "testinin artık boş bir işlev olarak tanımlandığını ve Bunun gibi bir işlem yapıp) Modülün test kapsamını arttırmak için bazen bir ay veya daha kısa bir sürede bir sprint (veya yarım sprint) alacağız.

Başka bir durum da ortaya çıkabilir: TDD kullanarak birkaç saat taahhütte bulunmadan bir proje üzerinde çalışıyorum. Sonunda taahhütte bulunduğumda işimi küçük parçalara bölmek istiyorum. (Tek bir dosyadaki değişikliklerin yalnızca bazılarını taahhüt etmek isteseniz bile Git bunu nispeten kolaylaştırır.) Bu, sorumun ne zaman işleme konulacağı ile ilgili olduğu kadar olduğu anlamına geliyor.

Kesinlikle yedekleme noktaları oluşturmayı taahhüt ediyorum derim . Bu, keşif testi için çok iyi çalışıyor ("Sadece kod tabanına bazı baskılar ekleyeceğim, çalıştırdığımda ve git reset --hardbittiğinde bunları kaldıracağım) ve prototip oluşturma için.

İş akışımda, mümkün olduğunda, kişisel bir kaynak kontrol branşında belirsiz işler yapıyorum. Böylece çalışabilir olana kadar deneyebilir, başarısız olabilir, gerekirse tekrar deneyebilir ve yalnızca gerçek çalışma kodum olduğunda daha büyük projelere katılabilirim.

TDD perspektifinden bakıldığında, "önce testi iade ediyor musunuz?" tamamen üzerinde çalıştığınız koda bağlıdır. Yeni kodsa, check-in yapmaya değen bir şey olana kadar hiçbir şeyi kontrol etmiyorsunuz. Ancak, önceden derlenmiş veya gönderilen bir kodda bulunan bir hataysa, hatayı yeniden üretmek için yapılan bir teste bakmak, BY ITSELF tarafından kontrol edilmeye değerdir. kod.

(Tabii ki, dükkanınızda herhangi bir ünite testi başarısız olursa ölen otomatik bir yapım süreci varsa, hatayı düzeltene kadar başarısız bir testi kontrol etmek istemeyebilirsiniz. Belge hataları "ve" hataları düzelt "tamamen farklı iki ekip tarafından yapılabilir.)