Birim testinden geçmek için minimum kodu yazmak - hile yapmadan!

TDD yaparken ve bir birim testi yazarken, test ettiğiniz "uygulama" kodunun ilk yinelemesini yazarken "hile yapma" dürtüsüne nasıl karşı çıkılır?

Örneğin:
Bir sayının Faktörünü hesaplayalım. Birim testiyle başladım (MSTest kullanarak).

[TestClass]
public class CalculateFactorialTests
{
    [TestMethod]
    public void CalculateFactorial_5_input_returns_120()
    {
        // Arrange
        var myMath = new MyMath();
        // Act
        long output = myMath.CalculateFactorial(5);
        // Assert
        Assert.AreEqual(120, output);
    }
}

Bu kodu çalıştırıyorum ve CalculateFactorialmetot bile olmadığından başarısız oluyor . Bu yüzden, test edilen yöntemi uygulamak için kodu ilk kez tekrarlıyorum ve testi geçmek için gereken minimum kodu yazıyorum .

Mesele şu, sürekli olarak aşağıdakileri yazmaya teşvik ediyorum:

public class MyMath
{
    public long CalculateFactorial(long input)
    {
        return 120;
    }
}

Bu teknik olarak doğrudur, çünkü gerçekten belirli bir test geçişi yapmak için gereken minimum koddur (yeşile döner), ancak açıkça bir "hile" olmasına rağmen, gerçekten bir faktoring hesaplama işlevini gerçekleştirmeye çalışmadığı için. Tabii ki, şimdi yeniden düzenleme bölümü, uygulamanın gerçek bir yeniden yapılandırması yerine, "doğru işlevi yazma" konusunda bir alıştırma haline geliyor. Açıkçası, farklı parametrelere sahip ilave testler eklemek başarısız olur ve yeniden yönlendirmeye zorlar, ancak bu testle başlamanız gerekir.

Öyleyse, benim sorum şu, hala sınamak için asgari kodu yazmakla birlikte gerçekten işlevsel tutmaya devam ederken, gerçekten başarmaya çalıştığınız şeyin ruhunda "denemek için minimum kodu yazmak" arasındaki dengeyi nasıl elde edersiniz?

Tamamen yasal. Kırmızı, Yeşil, Refactor.

İlk test başarılı.

Yeni bir giriş ile ikinci testi ekleyin.

Şimdi hızlıca yeşile dönün, iyi çalışan bir if-else ekleyebilirsiniz. Geçer, ama henüz bitmedi.

Red, Green, Refactor ün üçüncü kısmı en önemlisidir. Çoğaltmayı kaldırmak için refactor . Artık kodunuzda çoğaltmaya sahip olacaksınız. Tamsayı döndüren iki ifade. Bu kopyalamayı kaldırmanın tek yolu, işlevi doğru şekilde kodlamak.

İlk seferinde doğru yazma demiyorum. Sadece yapmazsan aldatma olmadığını söylüyorum.

Açıkça, nihai amacın anlaşılması ve bu hedefe uyan bir algoritmanın başarılması gerekir.

TDD, tasarım için sihirli bir madde değildir; kod kullanarak problemleri nasıl çözeceğinizi bilmeniz gerekir ve yine de bir test geçişi yapmak için bunu birkaç satırdan daha yüksek bir seviyede nasıl yapacağınızı bilmek zorundasınız.

TDD fikrini seviyorum çünkü iyi tasarımı teşvik ediyor; kodunuzu test edilebilir olması için nasıl yazabileceğiniz hakkında düşünmenizi sağlar ve genel olarak felsefe kodu genel olarak daha iyi bir tasarıma doğru iter. Fakat yine de bir çözümün nasıl oluşturulacağını bilmek zorundasınız.

Bir testi geçmek için en küçük kod miktarını yazarak bir uygulamayı büyütebileceğinizi iddia eden indirgemeci TDD felsefelerini tercih etmiyorum. Mimari hakkında düşünmeden, bu işe yaramaz ve örneğiniz bunu kanıtlar.

Bob Martin Amca diyor ki:

Teste Dayalı Geliştirme yapmıyorsanız, kendinize bir profesyonel denemek çok zordur. Jim Coplin bunun için beni halıda aradı. Bunu söylemekten hoşlanmadı. Aslında şu anki pozisyonu, Test Odaklı Gelişme'nin mimarileri yok etmektir, çünkü insanlar başka türlü düşünceleri terk etmek için testler yazıyor ve çılgınca koşuşturma testlerini geçmek için mimarlıklarını parçalara ayırıyor ve ilginç bir noktaya değindi. Bu, ayini kötüye kullanmanın ve disiplinin ardındaki amacı kaybetmenin ilginç bir yolu.

eğer mimarlığı düşünmüyorsanız, bunun yerine mimarlığı görmezden gelmek ve birlikte testler atmak ve geçmelerini sağlamak ise, binanın ayakta kalmasına izin verecek olan şeyi yok ediyorsunuzdur çünkü sistemin yapısı ve sistemin yapısal bütünlüğünü korumasına yardımcı olan katı tasarım kararları.

Sadece bir sürü testi bir araya getiremez ve on yıldan on yıl sonra on yıl boyunca geçmelerini sağlayamaz ve sisteminizin hayatta kalacağını varsayarsınız. Kendimizi cehenneme çevirmek istemiyoruz. Bu nedenle, iyi bir test odaklı geliştirici, her zaman büyük resmi düşünerek her zaman mimari kararlar alma bilincindedir.

Çok güzel bir soru ... ve @Robert hariç neredeyse herkesle aynı fikirde olmam gerekiyor.

yazı

return 120;

Bir faktoring fonksiyonunun bir test geçişi yapması zaman kaybıdır . Bu "aldatma" değil, ne de tam anlamıyla kırmızı-yeşil-refactor takip ediyor. Bu yanlış .

İşte nedeni:

• Hesaplama Faktörü , "sabit döndür" değil özelliktir. "return 120" bir hesaplama değildir .

• 'refactor' argümanları yanlış yönlendirilmiş; Eğer 5 ve 6 için iki test durumları varsa bir faktöriyel hesaplama olmadığı için, bu kod, yanlış hala hiç :

  if (input == 5) { return 120; } //input=5 case
  else { return 720; }   //input=6 case
  

• Eğer 'refactor' argümanını tam anlamıyla takip edersek, 5 test vakamız olduğunda YAGNI'yi çağırır ve fonksiyonu bir arama tablosu kullanarak uygulardık:

  if (factorialDictionary.Contains(input)) {
      return factorialDictionary[input]; 
  }
  throw new Exception("Input failure");
  

Bunların hiçbiri aslında bir şey hesaplamıyor, sizsiniz . Ve bu görev değil!

Yalnızca bir birim testi yazdığınızda, tek satırlı uygulama ( return 120;) yasaldır. 120 değerini hesaplayan bir döngü yazma - bu hile olurdu!

Bu kadar basit ilk testler son durumları yakalamanın ve bir defalık hataları önlemenin iyi bir yoludur. Beş aslında, başladığım giriş değeri değil.

Burada yararlı olabilecek bir kural: sıfır, bir, çok, çok . Sıfır ve bir faktörlü için önemli kenar durumlardır. Tek gömleklerle uygulanabilirler. "Çok" test durumu (örneğin 5!) Daha sonra sizi bir döngü yazmaya zorlar. "Çok" (1000 !?) test durumu, sizi çok büyük sayıları işlemek için alternatif bir algoritma uygulamaya zorlayabilir.

Sadece tek bir test yaptırdığınız sürece, testi geçmek için gereken minimum kod gerçektendir return 120;ve başka testlere sahip olmadığınız sürece kolayca saklayabilirsiniz.

Bu, aslında bu yöntemin DİĞER değerlerini kullanan testleri yazana kadar daha fazla tasarım ertelemenizi sağlar.

Test, şartname katedilebilen sürümü ve tüm eğer unutmayın o şartname diyor mükemmel o uyan faturası o f (6) = 120 olduğunu.

Bu şekilde "hile yapabiliyorsanız", birim testlerinizin hatalı olduğunu gösterir.

Faktoring yöntemini tek bir değerle test etmek yerine, bir değer aralığı olduğunu test edin. Veriye dayalı testler burada yardımcı olabilir.

Birim testlerinizi gereksinimlerin bir belirtisi olarak görün - test ettikleri yöntemin davranışını toplu olarak tanımlamaları gerekir. (Bu davranış odaklı gelişme olarak bilinir - geleceği ;-))

Öyleyse kendinize sorun - eğer birisi uygulamayı yanlış bir şeyle değiştirseydi, testleriniz yine de geçer mi yoksa “bir dakika bekle!

Bunu aklınızda bulundurarak, eğer tek testiniz sorunuzdaki ise, teknik olarak ilgili uygulama doğrudur. Sorun daha sonra zayıf tanımlanmış gereksinimler olarak görülür.

Sadece daha fazla test yaz. Sonunda, yazmak için daha kısa olurdu

public long CalculateFactorial(long input)
{
    return input <= 1 ? 1 : CalculateFactorial(input-1)*input;
}

göre

public long CalculateFactorial(long input)
{
    switch (input) {
       case 0: return 1;
       case 1: return 1;
       case 2: return 2;
       case 3: return 6;
       case 4: return 24;
       case 5: return 120;
    }
}

:-)

"Hile" testleri yazmak "Tamam" için yeterince küçük değerler için tamamdır. Ancak geri çağırma - ünite testi ancak tüm testler geçtiğinde tamamlanır ve başarısız olacak hiçbir yeni test yazılamaz . Eğer gerçekten bir sürü if ifadesi içeren bir CalculateFactorial metoduna sahip olmak istiyorsanız (ya da daha iyisi, büyük bir switch / case ifadesi :-) bunu yapabilirsiniz ve gerekli olan sabit bir numara ile uğraşıyorsanız) Bunu uygulamak sonludur (muhtemelen oldukça büyük ve çirkin olsa da ve belki de bir prosedür kodunun maksimum boyutunda derleyici veya sistem sınırlamaları ile sınırlıdır). Bu noktada eğer gerçektenTüm gelişimin bir birim testiyle yürütülmesi gerektiğinde ısrar edersiniz, sonucu if için tüm ifadeleri takip ederek gerçekleştirilebilecek süreden daha kısa bir sürede hesaplamak için kod gerektiren bir test yazabilirsiniz .

Temel olarak TDD, gereksinimleri doğru şekilde uygulayan bir kod yazmanıza yardımcı olabilir , ancak sizi iyi bir kod yazmaya zorlayamaz . Sana bağlı.

Paylaş ve Keyfini çıkar.

Robert Harvey’in önerisine% 100 katılıyorum, bu sadece testleri geçmekle ilgili değil, aynı zamanda genel hedefi aklınızda tutmanız gerekiyor.

"Sadece belirli bir girdi grubuyla çalıştığı doğrulandı" fikrinize bir çözüm olarak, xunit teorisi gibi veriye dayalı testleri kullanmayı öneriyorum. Bu kavramın ardındaki güç, kolayca girdilerin çıktılara spesifikasyonlarını oluşturmanıza izin vermesidir.

Factorials için bir test şöyle görünür:

    [Theory]
    [InlineData(0, 1)]
    [InlineData( 1, 1 )]
    [InlineData( 2, 2 )]
    [InlineData( 3, 6 )]
    [InlineData( 4, 24 )]
    public void Test_Factorial(int input, int expected)
    {
        int result = Factorial( input );
        Assert.Equal( result, expected);
    }

Hatta bir test verisi sağlayıcısı (geri döndüren IEnumerable<Tuple<xxx>>) uygulayabilir ve tekrar tekrar n ile bölen n-1 gibi bir matematiksel değişmezi kodlayabilirsiniz.

Bu testin çok güçlü bir yolu olduğunu düşünüyorum.

Hala hile yapabiliyorsanız, testler yeterli değildir. Daha fazla test yaz! Örneğin, giriş 1, -1, -1000, 0, 10, 200 ile testler eklemeye çalışacağım.

Yine de, gerçekten hile yapmaya karar verirseniz, o zaman sonsuz bir yazabilirsiniz. Bu durumda, kod incelemesi dışında hiçbir şey yardımcı olamaz. Yakında kabul testine yakalanırdın ( başka bir kişi tarafından yazılmış! )

Ünite testlerinde problem bazen programcıların gereksiz iş olarak görmeleridir. Onları görmenin doğru yolu, çalışmanızın sonucunu doğru yapmanız için bir araçtır. Öyleyse eğer if-o zaman yaratırsan, bilinçsizce göz önünde bulundurulması gereken başka durumlar olduğunu biliyorsun. Bu, başka testler yazmanız gerektiği anlamına gelir. Ve böyle devam ederek hile yapmanın işe yaramadığını anlayana kadar ve sadece doğru şekilde kodlamak daha iyidir. Hala bitmediğini hissediyorsan, bitmezsin.

Test seçiminin en iyi test olmadığını söyleyebilirim.

Şununla başlardım:

Faktoring (1) ilk test olarak

ikinci olarak faktörlü (0)

üçüncü olarak faktörlü (-ve)

ve önemsiz olmayan davalara devam

ve bir taşma dava ile bitirin.