TDD sadece teoride

Bir yıldan biraz daha uzun bir süre önce işten 9 ay ara verebilecek kadar şanslıydım. O zaman, C # becerilerimi geliştirmeye karar verdim. Bir sürü proje üzerinde çalışmaya başladım ve kendimi TDD'yi takip etmeye zorladım.

Bu oldukça aydınlatıcı bir süreçti.

İlk başta zordu, ancak zamanla daha fazla test edilebilir kod yazmayı öğrendim (bu, ortaya çıktığında, daha fazla SOLID kodu olma eğilimindedir) ve bu süreçte OO tasarım becerimi de arttırdım.

Şimdi işgücüne geri döndüm ve tuhaf bir şey fark ediyorum.

TDD'yi takip etmemeyi tercih ederim.

TDD'nin beni yavaşlattığını ve temiz bir uygulama tasarlamayı zorlaştırdığını biliyorum.

Bunun yerine, biraz (kitlesel) farklı bir yaklaşım benimsedim:

1. Dikey bir iş parçası seç
2. İşlevsel bir prototip geliştirin
3. Her şey güzel ve düzenli olana kadar refactor
4. Yazdığım güzel SOLID ve test edilebilir kodunu tekrar takdir edin.

1. adımın "test hedefimin genel yüzeyini tanımla" olmadığını ve 2. adımın "sözde kamusal yüzeyden bejesi test et" olmadığını fark etmiş olabilirsiniz. Ayrıca, adımlardan hiçbirinin test etmediğini fark etmiş olabilirsiniz. Test edilebilir kod yazıyorum, ancak henüz test etmiyorum.

Şimdi, herhangi bir testten vazgeçmediğimi açıkça belirtmek isterim. Yazdığım kod çalışıyor . Çalışıyor çünkü manuel olarak test ediyorum.

Ayrıca tüm otomatik testlerden de vazgeçmediğimi de açıkça belirtmek isterim. Burası benim sürecimin farklı olduğu yer. İşte bu yüzden bu soruyu soruyorum.

Teoride TDD. Uygulamada değil.

Sürecim biraz gelişti ve TDD ile çok verimli ve aynı zamanda makul derecede güvenli bulduğum testler arasında bir denge kurdum. Aşağıdaki gibi gider:

1. Düşey bir çalışma dilimini test akılda tutarak uygulayın, ancak herhangi bir test yazmayın.
2. Yolun aşağısında (örneğin, bir ay sonra) bu dilimin değiştirilmesi gerekiyorsa
   1. Çalışma biriminin doğru olduğunu garanti eden Birim Testleri, Entegrasyon Testleri, Davranış Testleri vb. Yazın.
   2. Kodu değiştirin
3. Bu dilimin değişikliğe ihtiyacı yoksa,
   1. Hiçbir şey yapma

Test yazma zorluğunu kod yazmadan önce kod değiştirmeden önce değiştirerek çok daha fazla çalışma kodu üretebildim. Ve test yazmaya başladığımda, bunlardan daha azını yazıyorum ancak neredeyse çok fazla zemin kaplıyordum (daha yüksek yatırım getirisi).

Bu süreci seviyorum, ama iyi ölçeklenemeyeceğinden endişeliyim. Başarısı, geliştiricilerin bir şeyleri değiştirmeden önce test yazma konusunda gayretli olmalarına bağlıdır. Ve bu oldukça büyük bir risk gibi görünüyor. Ancak, TDD'nin de aynı riski var.

Öyleyse, [BT] DD cehenneme mi gidiyorum, yoksa bu yaygın bir kodlama ve test şekli midir?

Bu şekilde çalışmaya devam etmek isterim. Bu sürecin uzun vadede çalışması için ne yapabilirim?

Projelerimdeki tek geliştiriciyim ve her şeyden sorumluyum: Gereksinimler toplama, tasarım, mimari, test, dağıtım vb. İşlemim bu yüzden çalışıyor.

Sürecin uzun vadede çalışması için kod yazılırken testleri yazacağım.

Hangi yaklaşımınıza aykırı görünüyor olabilir. Ancak soruyu sordun, o yüzden sana benim vereceğim:

Testleri koddan önce yazmak zorunda değilsiniz. bu saflığı unut. Ancak testler yazmak istiyorum etrafında o zaman.
Kodu çalıştırdıktan sonra, biraz ayarladınız, bazı hatalar çıkarıyorsunuz (burada saatlerce süren bir konuşmadan bahsediyoruz), daha sonra kodun ne yaptığına dair en üst düzeyde bilgi sahibi oluyorsunuz. Bilginizi yakalayan testler yazmak için harika bir zaman.

Bundan sonraya kadar bırakmak, bilginin (doğal olarak) zamanla azalacağı anlamına gelir.

Bu ayrıca, hiç ayrılmanız ve başkasının devralması durumunda, neyin ne yaptığını belgelememek (testler yoluyla) derhal teknik borcunuz olmayacağı anlamına gelir.

En önemlisi, "bir gün" gelmeyebilir. Ya bir otobüs çarpabilir ya da yeni maceralar için otobüse binebilirsiniz.

Son olarak, manuel testler ölçeklenmez ve sık sık son kullanıcı tarafından kullanılan tüm cihazları kapsamaz.

TDD'nin% 100 uygulanması zor olsa da, yaklaşımınızda bir kusur var

1. Çalışan bir dikey dilim iş uygulayın

   1.1 1 yıl geçer ....

   1.2 Yeni bir dev proje üzerinde çalışmaya başladı

2. Bu dilimin değiştirilmesi gerekiyorsa

   2.3 Ayrıştırma 'Temiz Kodlama' stil yöntemi adları ve parametreleri 'GetUnicorn (colourOfUnicorn)'

   2.4 xml yorumlarını okuyun 'Altın boynuzlu at (sürme için) (obvs)'

   2.5 Orijinal devi avla

   2.6 Kodun ne yapması gerektiğini hatırladıklarını umarım

   2.7 Hepsini açıklamalarını sağlayın.

3. İş diliminin doğru olduğunu umduğumuzu garanti eden Birim Testleri, Entegrasyon Testleri, Davranış Testleri vb. Yazın.

4. Kodu değiştirin

Değişikliklerin yapılması gerektiğinde ünite testlerinin gerçekten değerlerini gösterdiğini tespit etmekte haklısınız.

Hem Daniel Hollinrake hem de Ewan ile aynı fikirdeyim, eğer sadece-eğer-değiştirmeyi test etmenin şu ana kadar iyi çalıştığının ilk kilit noktası şudur:

I am the sole developer on my projects and I am responsible for everything

ve muhtemelen ikinci bir kilit nokta şudur:

you're producing nice clean code

TDD'nin tek programcılar için büyük bir verimlilik artışı getirdiğini düşünmüyorum ve zaten iyi temiz kod yazıyorsanız, kodunuzun kalitesini büyük ölçüde iyileştiremeyebilir.

Ancak, TDD, özellikle de başka bir şeyi bozmadan kodu değiştirme zamanı geldiğinde, kötü / deneyimsiz / eski programcıların kodunun kalitesini kesinlikle artıracaktır. Ve hatta dahası, kodu değiştiren kişi, kodu ilk olarak yazan kişi değilse veya birkaç ay geçtiyse.

Başka bir deyişle, TDD'nin kodunuzun kalitesini (sizin de bildiğiniz gibi) geliştirmek için iyi bir uygulama olduğunu, ancak ortalama veya vasat programcılar ile çalışırken (örneğin, farklı departmanı veya farklı bir şirket) çalışan solo daha çok yaygın bir durumdur.

Benim için kilit olan bu gibi görünüyor:

Projelerimdeki tek geliştiriciyim ve her şeyden sorumluyum: Gereksinimler toplama, tasarım, mimari, test, dağıtım vb. İşlemim bu yüzden çalışıyor.

Bu sizin için çalışıyor ve güzel temiz kodlar üretiyorsunuz (Sanırım!). Yapmanız gereken tek şey, diğer geliştiricilerin gelip değişiklik yapma konusunda kendinden emin olmaları için bir test donanımı oluşturmak. Ayrıca test kablo demeti, kodun davranışında tutarlılığı sağlar.

Bence senin yaklaşımın benimkine benziyor. Ben genellikle projelerimdeki tek geliştiriciyim. TDD takdirinin daha küçük fonksiyonlar ve daha temiz kodlar yazmamı sağladığını öğrendim ancak kodu bir test kablo demeti olarak yazarken testler ekliyorum. Bu şekilde kod geliştikçe ve işlevsellik değiştikçe, değişiklik yapma konusunda kendime güvenim emin olabilirim.

Test yazmanın ikinci bir nedeni, onların bir tür dokümantasyon olduğunu hissetmemdir. Bir fonksiyonun yaratılmasının ardındaki nedenlerimi açıklayabilirler. Fakat burada, Davranış Odaklı Gelişme hakkında daha fazla düşünüyorum.

Birim Testi, kod tutma sorunuyla mücadele etmekle ilgilidir. TDD ile kod yazmaktan daha hızlı olduklarını söyleyen insanlar varken, test yazmadan daha yeni kod yazabildiğinize şaşırmıyorum.

Test etmeden uygulayabildiğim sorunları değiştirmeden hemen önce:

Sık sık acele değişiklikleri yapmak gerekir

Genel olarak yalnızca ihtiyaç duyduğunuzda testler yazarak zaman kazanmanıza rağmen, her zaman eşit değildir. Kriz modundayken 1 saatten fazla tasarruf etmek için 2 saat yazma sınavı - tamamen buna değer.

Kodları yazdığım sırada testleri yazmak daha kolay

Ünite testlerini uygun şekilde yazmak için test ettiğim kodu anlamanız gerekir. Birim testini sıklıkla bir anlama alıştırması olarak kullanırım, ancak mevcut kodu birim test etmek zaman alıcı olabilir çünkü mevcut kodu anlamak zaman alıcıdır. Siz kodu yazarken testler yazmakla kontrast oluşturursunuz ve kodu çok daha hızlı bulacaksınız çünkü zaten kodu anladınız - sadece yazdınız!

Michael Feathers, eski kodun tanımı testsiz koddur. Tanımı ile aynı fikirde olup olmadığınıza bakılmaksızın, mevcut kodu değiştirme maliyetinin önemli bir kısmının hala beklendiği gibi çalışmasını sağlamak olduğu, genellikle beklenen davranışın ne olduğu net değildir.

Birim testleri yazmak, doğru davranışın ne olduğunun bir anlayışını kodlamanın yanı sıra, “geleceğin” için bu davranışın hala doğru olup olmadığını kontrol etmenin kolay bir yolunu sağlayarak maliyeti telafi eder.

Bu iyi bir soru ve FWIW İki kuruşa atacağım.

Yaklaşık bir yıl önce, kodlamadan önce test yazmanıza gerek kalmadan , genel olarak test yazmaya zorladığınız, yerleşik bir mekanizmaya sahip bir platform olan Salesforce'da kodlama yapıyordum .

İşe yaraması, sistemin sizi test yazmaya zorlayacağı ve kodunuzun yüzde olarak test edilen satır sayısını hesaplayacağıydı. Üretim durumunuzdaki tüm kodlar% 75 testin altına düşerse .. Salesforce artık çalışmaz.

Bunun sonucu, Salesforce'da her ne zaman bir şey yapsanız, testleri yazmak veya güncellemek zorunda kalmanızdı. Bunun Salesforce'un pazar payı üzerinde büyük bir etkisi olduğundan emin olmakla birlikte, bir geliştiricinin ömrü açısından kıçında büyük bir acı vardı .

Sadece küçük bir bilete binmeye çalıştığınız zamanın çoğu, ve sonra testler gelir ve sadece çalışmalarını bildiğiniz bir özellik için geliştirme sürenizi iki katına çıkarır .

Daha sonra garip TDD kavramı, departmanımızdan aşağı doğru veritabanlarımıza geçti. Mimarlarımız BT departmanımızın her yönüyle kapsamlı testler yapmak istedi. Kıçından hafif bir ağrı, kıçından daha da büyük acı çek.

O zaman TDD bana hiçbir zaman mantıklı gelmedi ve şimdi bile hala anlamıyor. Şu anki görevimde yazdığım işlevselliklerin çoğu, bahsettiğinizle benzer bir mekanizma içinde gerçekleşiyor: işe yarayana kadar rafine ettiğim dikey dilimlerde. O eski roldeyken, ve hala şimdi kodumun gerçekten yazana kadar ne yapacağımı bilemiyorum , bu yüzden sadece yazacağım kodu çalıştırmak için testler yazabiliyorum. Bana mantıklı gelmiyor, hantal ve çoğunlukla zaman kaybı.

Bütün bunlar, testler dünyadaki her şeyi doğru yapan harika ve büyülü şeylerdir . Kodunuzu doğrular, uygulamanızın düşündüğünüzü yapmasını sağlar ve genellikle her şey daha yumuşak olur. Öyleyse soru, testlerinizi kodlamadan önce mi yoksa kodlamadan sonra mı yazmanız gerektiği değil, soru, test etmek için ne kadar zaman ayıracağınızdır. Asıl sorun, en azından yazılım geliştirme deneyimimde. Test yapmak zaman ve para alır ve bunu rekabetçi çıkarlar çerçevesinde yapmak zorundasınız.

Ve böylece, genel olarak sizinle aynı fikirdeyim: TDD pratikte biraz garip ve hantal. Bu noktada , şu andaki durumunuzda en iyi olanı aklınızda bulundurmanız gerekir . Kritik kod yazıyorsanız, genel olarak test edildiğinden emin olun. Zamanınız varsa, TDD'yi bir deneyin ve sürece bir şey ekleyip eklemediğini görün.

Yaklaşımını tavsiye edemedim.

Eğer yaklaşımınızı kullanırsam, örneğin aşağıdaki gibi olur (ev uygulamadır):

1. Ailem için bir duvar örgüsü olarak ya da yeni başlayanlar için bir ev inşa etmeye başladım.
2. Çocuk odaları, misafir odaları gibi ihtiyaçları biliyorum ve "prototip" evimi inşa etmeye başladım.
3. Birkaç kez sonra "prototip" eviniz yapılır.
4. Yapının el ile yeterince kararlı olup olmadığını aramaya başladım. Bu yüzden çok ağırlıklar alıp birinci kattaki farklı odalara getiriyorum. Ailemle bir odada oturduğumda tavanı kırmadığımdan emin olmak için. Ama kırılıyor ve yeniden ateşlemeye başlıyorum. İlk önce tüm kütleyi temizle. Daha sonra yeni oluşturun ve yeterince kararlı olana kadar manuel olarak tekrar test edin.
5. Daha sonra aileme taşınıyorum. Her şey yolunda.
6. Bir güve sonra kuzenlerim ve ebeveynler bizi ziyarete geliyorlar. Ancak evimize girmeden önce, birinci kattaki odalardan birine oturduğumuzda tavanın kırılmadığından emin olmak için bir mimar ve inşaat mühendisi ödemeleri gerekir.
7. Mimar ve inşaat mühendisinin çok işi var çünkü başlayacak hiçbir şeyleri yok. Bu yüzden evime gitmeleri ve nasıl inşa ettiğime bakmaları gerekiyor.
8. Ve yine yeterince kararlı değil. Bu yüzden birinci katın zeminini yeniden döşemek zorundalar.
9. Ama ondan sonra her şey yolunda ve hepsi güvenli bir şekilde evime girebilir.

Bu yüzden, yaklaşımı ile evi inşa etmeden önce yaklaşımınız çok zaman ve çok fazla bilgiye mal olur. Veya biraz zaman alır! Ayrıca, gereksinimler değiştiğinde kodunuz için başka testler yazmalarına izin vermek de hoş olmayan Gentleman değil.

Bu yüzden bir "prototip" programlamadan ve yeniden düzenlemeye başlamadan daha iyi bir yaklaşım var. Bir prototip programlamak yerine "Uygulamanızın UML'sini kullanarak bir Tasarım yapın.

1. UseCase diyagramı oluşturun. Başlamak için draw.io kullanabilirsiniz .
2. Daha sonra davranışı belirlemek için UseCases'inizi temel alan bir EPK diyagramı oluşturun. (Uygulamanızın DAVRANIŞI) Kodlanmış bir prototipten, refaktörden daha hızlı refaktör. Özellikle de bir acemisin.
3. Bir sınıf Şeması oluşturun. (Başvurunuzun Yapısı)
4. Davranışın uygulanmasında nerelerde sorun yaşayabileceğinizi belirleyin.
5. Bu davranışı nasıl uygulayabileceğinizi belirlemek için belki de 10 veya 20 kod satırlı basit bir prototip yazın. Yeni başlayanlar için iyi. Veya bir eğiticiyi izleyin, oradaki diğer örnek uygulamaların kaynak koduna bakın. Nasıl çözdüler?
6. Kodlamaya başla. UseCase'inizin başarılı testlerini yapın. Bu farklı şekillerde yapılabilir. Öncelikle, test için gerekli olan ve UseCase için gerekli olan tüm Yapıları oluşturun. Kullandığınızda Kurumsal Architekt yapısı sizin için oluşturulabilir. Diyagramlarına göre. Veya Test'i kablolarken yapıyı oluşturun. Yani hiçbir derleme hatası görünmüyor. Burada bahsettiğim, SADECE başvurunuzun DAVRANIŞINI test etmeniz gerektiğidir. Sahip olduğunuz UseCases.
7. UseCase'inizin davranışını uygulayın.
8. Başarılı olduktan sonra UseCases istisnalar için Testler yazmaya başlar. Ve testleriniz geçerli olduğunda yeşil renkleri gördüğünüzde her zaman iyi hissettirir;)
9. Ve bitti.

Elbette bu yaklaşımın UML'de de biraz Bilgi gerektirmesi gerekir, ancak öğrenmesi hızlıdır. Sınıfı yeniden adlandırmak veya bir digramdaki okları IDE'nizde yapmaktan her zaman daha hızlıdır. Ancak, test çerçevelerinin kullanımını öğrenmek başlangıçta daha yorucu olacaktır. Açık kaynak kodlu projelerin deneme testini yapmak ve nasıl çalıştıklarını görmek için en iyisi burada. Ancak, test odaklı bir uygulama başlattığınızda bir sonraki uygulama çok daha hızlı olacaktır. Ve bence her şeyin yolunda gittiğini bilmek güzel bir duygu.

Bu yüzden sadece yaklaşımları oyluyorum çünkü yeni başlayanlar için çok zaman alıyorlar ve sonuçta iyi değiller. Yapınız ve davranışınız arasında temiz bir sınır oluşturmak için Etki Alanı tarafından yönlendirilen Tasarım'ı ve Çok Etki Alanı Ayarla altında iki Paket (yapı olarak adlandırılan bir paket ve diğer adı verilen davranış) kullanabilirsiniz. Ayrıca testleriniz için. Bu dışarı basit örnek onay Örnek java ile yazılmış.

Yazdığım kod çalışıyor. Çalışıyor çünkü manuel olarak test ediyorum.

Küçük değişikliklerden sonra koşullarınızın olası tüm dallarını manuel olarak test ettiniz mi? Manuel testinizin geri bildirim döngüsünü ne kadar süre alır. Otomatikleştirilmiş testlerle geribildirim döngüsüne ne kadar yakınsınız.

Otomatik testler (önce test etmeli ya da etmemesi gerekmez), kodunuzda daha hızlı geri bildirim döngüsü sağlayarak hızlı gitmenizi sağlar.

Altı ay sonra bir koşulu manuel olarak test etmeyi hatırlayacağınızdan emin misiniz - lütfen test etmek için tüm önemli koşulu belgeleyeceğinizi söylemeyin - çünkü bir tür belge / yorum yazmak test yazmaya eşittir (çalıştırılabilir belgeler)

• Dikey bir iş parçası seç

• İşlevsel bir prototip geliştirin

• Her şey güzel ve düzenli olana kadar refactor

Ve tekrar: yeniden yapılanma sırasında, yeniden yapılanmadan etkilenen tüm mantığı manuel olarak test ettiniz mi? Yeniden yapılanma değişimini test etmek ne kadar zaman alır? Yeniden düzenleme yapmak bazı kodları ihlal ederse, ara vermeniz ne kadar zaman alır?

• Yazdığım güzel SOLID ve test edilebilir kodunu tekrar takdir edin.

Hoşunuza giden güzel ve temiz kod çok özneldir. Kodunuz sizin için temiz ve makul olabilir. Kodunuzun gerçekten okunabilir, anlaşılabilir ve test edilebilir olup olmadığını kontrol etmenin en iyi yöntemi, diğer geliştiriciler tarafından yapılan testler ve kod incelemeleridir.

Yolunuzu çok üretken buldunuz, çünkü sadece kodla çalışan geliştirici sizsiniz ve bence, çünkü sadece bu projede çalışmaya başladınız (Bu projede kaç yaşında çalışıyorsunuz? 6 - 8 ay?).
Yazdığın her şeyi hala hatırlıyorsun ve olası sorunların nedenini anlayabiliyorsun. Projenizin 2-3 yıl sonra başından itibaren test yazmaya başlayacağınıza eminim - çünkü hiçbir şeyi unutmadığınızdan emin olmak istiyorsunuz.

Eğer asla hata yapmazsanız, gerçekten testlere ihtiyacınız olmaz. Çoğu geliştirici hata yapar, ancak asla yapmazsanız ve gelecekte hiçbir zaman hata yapamayacağınızdan eminiz (ve projedeki tek kişi sizsiniz), zaman testlerini harcamak için hiçbir neden yok.

Ancak çözümünüz yarı yarıyadır, çünkü kodu değiştirirken testler yazmayı teklif edersiniz, ancak aynı zamanda yönteminiz kodun hangi bölümleri için test yazacağınıza karar verirken asla hata yapamayacağınızı varsayar. Bu, yalnızca bir değişimin hangi alanları etkileyebileceğini her zaman mükemmel bir şekilde anlarsanız çalışır. Birçok ortak geliştiricinin (elbette siz değil!) Bir değişiklik yapmak için deneyimlendiğini ve beklenmeyen bir yerde yapılan bir testin başarısız olduğunu düşünüyorum, çünkü bir hata yaptınız.

Elbette iyi mimari, SOLID ilkeleri vb. Bunun olmasını engellemeli, ancak çoğu geliştirici mükemmel değildir ve bu nedenle sistem genelinde yapılan testlerin değerli olmasının nedeni budur.