TDD'nin “Açık Uygulama” önce kod anlamına mı geliyor?

Arkadaşım ve ben nispeten yeni TDD'yiz ve "Açık Uygulama" tekniği hakkında bir anlaşmazlık yaşıyoruz (Kent Beck'in "TDD By Sample" dan). Arkadaşım, eğer uygulama açıksa, o yeni davranış için herhangi bir testten önce devam etmeli ve yazmalısınız demektir . Ve aslında kitap şöyle diyor:

Basit işlemleri nasıl gerçekleştirirsiniz? Sadece uygulayın.

Ayrıca:

Bazen bir operasyonun nasıl uygulanacağını bildiğinizden emin olabilirsiniz. Devam et.

Yazarın ne anlama geldiğini ilk önce test etmeniz ve sonra "sadece uygulamanız" - uygulama aşamasında daha küçük adımlar gerektiren "Sahte Yap ('Yapana Kadar') ve diğer tekniklerin aksine olduğunu düşünüyorum. Ayrıca bu alıntılardan sonra yazar "Açık Uygulama" yaparken "kırmızı çubuklar" (başarısız testler) elde etmek hakkında konuşuyor - nasıl bir test olmadan kırmızı bir çubuk alabilirsiniz ?.

Yine de kitaptan "bariz" diyen bir alıntı bile bulamadım.

Ne düşünüyorsun? İlk önce veya sonra uygulamanın "açık" olduğu zaman (tabii ki TDD'ye göre) test etmeli miyiz? Bunu söyleyen bir kitap veya blog yazısı biliyor musunuz?

Yorumunuza katılıyorum - hala Red Green Refactor, sadece Refactor biti dışında;)

Bu nedenle, önce başarısız bir test yazın, sonra yavaşça "mümkün olan en basit" bir tasarım oluşturmak yerine bariz çözümü uygulayın.

Bunu söyleyen bir kitap veya blog yazısı biliyor musunuz?

Beck'in kitabının bunu söylediğini iddia ediyorum.

Söylemeye devam ediyor

Ancak, yalnızca Açık Uygulama'yı kullanarak, kendinizin mükemmelliğini talep edersiniz. Psikolojik olarak, bu yıkıcı bir hareket olabilir. Yazdıklarınız testi geçebilecek en basit değişiklik değilse ne olur? Eşiniz size daha da basit bir tane gösteriyorsa ne olur? Sen başarısızsın! Dünyanız etrafınızda parçalanıyor! Ölürsün. Sen donuyorsun.

Kodu yapmadan önce kodu yazarak testi geçmeyi nasıl sağlayabilirsiniz?

Açıkçası burada zor ve hızlı kurallar yok, her şeyden önce çevikti, bu yüzden yinelediğimiz gibi adapte edebiliriz ve yapmalıyız :)

Kısmen basit operasyona bağlı olacak ve TDD'yi giderek daha fazla uyguladığınızda, düzenli olarak kötü bir şekilde test ettiğiniz veya gerçekten hiç test etmediğiniz şeyleri bulacaksınız, hepsi öğrenme eğrisinin bir parçası.

Ayrıca TDD'nin, canlı koda geçmeden önce arayüzü ve uygulamayı test etmenize izin verdiğini unutmayın.

Bir şeyi nasıl uygulayacağınızı biliyor olabilirsiniz, ancak yol boyunca bazı ince ayarlar yapmadan veya bir veya iki ve altı ay sonra bir şeyi değiştirdiğinizde koddan geçmeden ilk kez ne zaman mükemmel bir sınıf / yöntem vb. Yazabilirsiniz? daha fazla güven ve tekrar testlerin sanal alanında.

Elbette, testler kodu ilk kez daha doğru yazdığınız anlamına gelmez, ancak değişiklikleriniz test tarafından yönlendirilir ve testler kodun ilk müşterisi olur ve testler çok düşük maliyetlidir ve daha da önemlisi değiştirme riski yoktur gelişirken daha fazla güven ve özgürlüğe sahip olursunuz.

Gerçekten iyi bir kapsama alanı ve daha yüksek kalite elde etmeye çalışıyorsanız, o zaman başlamak için daha fazla testin yanına hata yaparsanız, TDD'yi daha fazla uygularken, ihtiyacınız olan kapsama düzeyi hissine sahip olacaksınız.

Önemsiz kod için hiç bir birim test olmaması gerektiğini öğrendim.

örnek: Bir yöntemi yerel bir değişkenle eşleyen bir java alıcısı / ayarlayıcı yönteminiz varsa, bunun için bir birim testi aşırıya kaçar.

belki yazarın anlamı budur

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."