TDD ile yeni bir projeye başlanması

TDD okuyorum ve aynı zamanda uygulamanın tasarımını tanımlamanıza yardımcı olduğunu okudum, değil mi?

Bu yüzden daha iyi anlamama yardımcı olacak yeni bir proje oluşturmaya karar verdim.

Adını, e-posta adresini, ülkesini (listeden bir tane seçecek) ve telefon numarasını soracak basit bir kullanıcı kayıt sistemi oluşturmak istiyorum.

Yani soru ...

VS 2010'da yeni bir çözüm oluşturdum, yeni bir Test projesi ekledim ve hangi testleri yazacağımı bilmiyorum!

Tasarımı tanımlamama yardımcı olacağından buraya hangi testleri yazabilirim?

Herhangi bir yardım için teşekkürler!

Birim testleri yazarken, uygulamanızın davranışını test edersiniz, bu nedenle sorulması gereken önemli soru , uygulamanızın ne yaptığıdır ? İşte bir başlangıç:

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

Sadece bir test projesi oluşturmak ve bazı test yöntemleri yazmak bir tür TDD'dir, ancak tecrübelerime göre, bilinen bir API'nin bulunduğu bir kütüphane üzerinde çalışmadığınız ve yöntem çağrılarının doğrudan kullanıcı tarafından beklenen bir şeye karşılık gelmediği sürece çok yardımcı olmaz. . Doğru testler listesi bulmanız gerekir ve önemsiz olmayan bir uygulama için bunu yapmak gerçekten zor olabilir.

SpecFlow'u denemenizi tavsiye ederim - testleri uygulamadan güzel bir şekilde ayrılmış olarak tanımlar ve özellik dosyalarının yapısı sizi gerçekten neyi test ettiğinizi düşünmeye zorlar.

Bir özellik tanımladığınızda,

When a user is saved
Then the user should exist

Bu noktada bir kod dosyasında olmadığınız için, kullanıcı oluşturmak için hangi yöntemin çağrıldığı veya hatta hangi sınıfta uygulandığı gibi uygulama ayrıntılarını düşünmek istemezsiniz. Farklı uygulamalar seçmek için etiketleri kullanabilirsiniz, bu nedenle "kullanıcı kaydedildi" nin CreateUser'a bir çağrı yapılması veya bir tarayıcı açılması ve bir form göndermesi anlamına gelmez.

Tanımlanan özelliklere sahip olduğunuzda, tüm testler oluşturulur ve adım tanımlarını ve test edilen gerçek uygulama kodunu uygularken geçmeye başlar.

Basit bir uygulama için sadece özellik dosyaları oluşturabilirsiniz, ancak daha karmaşık bir şey için önceden daha eksiksiz bir spesifikasyon bir araya getirmek yararlıdır. Bunun için bir iPad mindmapping uygulaması kullanıyorum, ancak en rahat olduğunuz aracı kullanabilirsiniz.

"Kullanıcı kaydı" gibi üst düzey özelliklerin bir listesiyle başlayın. Bunlar doğrudan test yazmak için çok geniş olma eğilimindedir, bu nedenle bunları açıkça tanımlanabilen ve genellikle "Kullanıcıyı kaydet" veya "Mevcut kullanıcıyı görüntüle" gibi belirli bir kullanıcı işlemiyle eşleştirebilen alt özelliklere bölün.

Bu alt özelliklerin her biri, özelliğin çalışıp çalışmadığını tamamen tanımlayan, "Geçerli bir kullanıcıyı kaydedebilir" ve "Yinelenen kullanıcı adıyla bir kullanıcı kaydedilemiyor" gibi şeylerin birlikte tanımlandığı senaryoların bir listesine ihtiyaç duyacaktır.

Bu listeyi oluştururken, yapının nerede ayarlanması gerektiği genellikle netleşecektir - bir özellik için herhangi bir senaryo testi bulamazsanız veya bir özellikte çok fazla sonuç alırsanız, bu özellik muhtemelen yanlış seviye ve bölünmesi veya değiştirilmesi gerekiyor.

İlk denemeleri TDD'ye yedeklemenin yanı sıra bazı kodları da okumayı iyi buldum. Konu hakkındaki wikipedia makalesi çok iyi ve çok çeşitli diğer kaynaklara yol açacaktır. Özellikle Kent Beck tarafından bir şeyler arayın - bir çeşit TDD'nin babası.

Salınımına girmenize yardımcı olabilecek başka bir şey de bazı kataslar yapmaktır - basit, neredeyse akılsız eğitim egzersizleri. Roy Osherove'de iyi olanlar var.

Bunun ötesinde, TDD'nin temel fikirlerini aklınızda bulundurun - her seferinde bir test yazın, ve önceki tüm testler geçene kadar devam etmeyin. Sadece mevcut testi tatmin etmek için yeterli kod yazın, daha fazla yazmak için ayartma kaçının. Gittikçe, her seferinde durun ve kodu veya testleri temizleyip temizleyemeyeceğinizi düşünün. Her zaman kırmızı (başarısız test), yeşil (başarılı test), refactor döngüsünde gelişir.

Başlamanız için belki de isim gereksiniminizle başlayın. Neye ihtiyacınız olacak?

Muhtemelen bir sınıfa ihtiyacınız olacak. Bunun için bir test yazın (bazı insanlar bunu atlar, ancak egzersiz yaparken bunu yapın) ve sınıfı yazın.

Daha sonra sınıfınızın bir isim saklaması gerekecektir. Sınıfınızın gerçekten yapabileceğini kanıtlayan bir test yazın. Sonra tekrar testi geçmek için kod yazın.

O zaman belki de daha fazla iş kuralınız var. Belki adınızın en az karakter uzunluğunda olmasını istersiniz. Testi yazın, başarısız olduğunu görün, kodu yazın.

Ve bunun gibi...

Sanırım TDD fikrini kısa bir cevapla vermek mümkün değil. Hissetmek için onu uygulayan birini "görmeniz" gerekir. Bu konuda şimdiye kadar bulduğum en iyi kaynak http://pragprog.com/titles/achbd/the-rspec-book . Bana söylemeden önce Ruby senin dilin değil: Bob Amca'nın önsözünü oku! ;-)

E-posta alanına birden fazla farklı değer eklemeye çalışan, bazıları geçerli olan ve diğerleri olmayan bir test oluşturmak isteyebilirsiniz. Tüm testler beklenen değeri verene kadar gelişmeyi bırakmayın. Onun gibi şeyler.

Sistemi tanımladığınız gibi, uygulama düzeyinde yalnızca bir test vardır:

[Test] genel void Save_and_retrieve_user (Dize adı, Dize e-postası, ...) {// Kaydet // Al // Doğrula}

Gereksinimleri geliştirirken daha fazla test ekleyin.