Sayılar bir şey ifade etmiyorsa, birim testlerinde sihirli sayılar kabul edilebilir mi?

Birim testlerimde, ne yaptığını görmek için koduma rastgele değerler atarım. Örneğin, bunun foo(1, 2, 3)17'ye dönmesi gerektiğini biliyorsanız , şunu yazabilirim:

assertEqual(foo(1, 2, 3), 17)

Bu sayılar tamamen keyfidir ve daha geniş bir anlamı yoktur (bunlar üzerinde de test etmeme rağmen, örneğin sınır koşulları değildir). Bu numaralar için iyi isimler bulmakta zorlanıyorum ve böyle bir şey yazmanın const int TWO = 2;yararsız olduğu açık. Testleri böyle yazmak uygun mudur, yoksa sayıları sabitler olarak mı belirlemeliyim?

In Are tüm sihirli numaraları aynı yarattı? , anlamın bağlamdan açık olması durumunda, sihirli sayıların tamam olduğunu öğrendik, ancak bu durumda sayıların aslında hiçbir anlamı yoktur.

Gerçekten ne zaman hiçbir anlamı olmayan numaralara sahipsin?

Genellikle, sayılar herhangi bir anlama geldiğinde, kodu daha okunaklı ve kendi kendine açıklayan hale getirmek için bunları test yönteminin yerel değişkenlerine atamalısınız. Değişkenlerin adları, en azından değişkenin değerini değil, değişkenin ne anlama geldiğini yansıtmalıdır.

Örnek:

const int startBalance = 10000;
const float interestRate = 0.05f;
const int years = 5;

const int expectedEndBalance = 12840;

assertEqual(calculateCompoundInterest(startBalance, interestRate, years),
            expectedEndBalance);

İlk değişkenin adlandırılmadığını HUNDRED_DOLLARS_ZERO_CENT, fakat startBalancedeğişkenin anlamının ne olduğunu, ancak değerinin herhangi bir şekilde özel olduğunu belirtmediğini unutmayın.

Ne yaptıklarını görmek için rastgele sayılar kullanıyorsanız, gerçekten aradığınız şey muhtemelen rastgele oluşturulmuş test verileri veya özellik tabanlı testlerdir.

Örneğin, Hipotez , bu tür testler için harika bir Python kütüphanesidir ve QuickCheck'e dayanır .

Normal bir birim testini aşağıdaki gibi bir şey olarak düşünün:

1. Bazı verileri ayarla.
2. Veriler üzerinde bazı işlemler gerçekleştirin.
3. Sonuç hakkında bir şey söyleyin.

Hipotez, bunun gibi görünen testleri yazmanıza izin verir:

1. Bazı özelliklere uyan tüm veriler için.
2. Veriler üzerinde bazı işlemler gerçekleştirin.
3. Sonuç hakkında bir şey söyleyin.

Fikir, kendinizi kendi değerlerinizle sınırlamak değil, fonksiyonlarınızın özelliklerine uyduğunu kontrol etmek için kullanılabilecek rastgele olanları seçmek. Önemli bir not olarak, bu sistemler genel olarak başarısız olan herhangi bir girişi hatırlar ve ardından bu girişlerin gelecekte daima test edilmesini sağlar.

3. nokta bazı insanlarla kafa karıştırıcı olabilir, bu yüzden açıklığa kavuşturalım. Kesin cevabı verdiğiniz anlamına gelmez - bu keyfi bir giriş için yapmanız kesinlikle mümkün değildir. Bunun yerine, sonucun bir özelliği hakkında bir şey iddia ediyorsunuz . Örneğin, bir listeye bir şey ekledikten sonra boş kalmayacağını veya kendi kendini dengeleyen bir ikili arama ağacının gerçekten dengelendiğini (belirli bir veri yapısının sahip olduğu ölçütleri kullanarak) iddia edebilirsiniz.

Genel olarak, rastgele sayıları kendiniz seçmek muhtemelen oldukça kötü bir şey - bu gerçekten de tam bir katma değer oluşturmuyor ve okuyan birinin kafasını karıştırıyor. Bir grup rasgele test verisinin otomatik olarak üretilmesi ve etkin bir şekilde kullanılması iyi. Tercih ettiğiniz dil için bir Hipotez veya QuickCheck benzeri kütüphane bulmak, muhtemelen başkalarına anlaşılır kalırken hedeflerinize ulaşmak için daha iyi bir yoldur.

Birim test adınız içeriğin çoğunu sağlamalıdır. Sabitlerin değerlerinden değil. Bir testin adı / dokümantasyonu, testte hangi büyü sayılarının bulunduğunu ve uygun bağlamı ve açıklamasını vermelidir.

Bu yeterli değilse, bir miktar dokümantasyon sağlayabilmelidir (değişken ismi veya dokümanı aracılığıyla). Fonksiyonun kendisinde umarım anlamlı adlara sahip parametrelere sahip olduğunu unutmayın. Argümanları adlandırmak için bunları testinize kopyalamak oldukça anlamsız.

Ve son olarak, eğer en içkisiz olanlar bunun zor / pratik olmadığı kadar karmaşıksa, muhtemelen çok fazla karmaşık fonksiyonlara sahip olabilirsiniz ve bunun neden böyle olduğunu düşünebilirsiniz.

Testleri ne kadar titizlikle yazarsanız, gerçek kodunuz o kadar kötü olur. Testi netleştirmek için test değerlerinizi isimlendirme ihtiyacı duyuyorsanız, gerçek yönteminizin daha iyi adlandırma ve / veya dokümantasyona ihtiyaç duyması şiddetle tavsiye edilir. Testlerde sabitleri isimlendirmek için bir ihtiyaç bulursanız, neden buna ihtiyaç duyduğunuza bakardım - muhtemelen sorun testin kendisi değil uygulamadır.

Bu, büyük ölçüde test ettiğiniz işleve bağlıdır. Bireysel sayıların kendi başlarına özel bir anlama sahip olmadığı birçok durum biliyorum, ancak bir bütün olarak test durumu düşünceli bir şekilde oluşturulmuş ve özel bir anlamı var. Bir şekilde belgelenmesi gereken şey budur. Örneğin, eğer üç sayının üçgenin kenarlarının geçerli uzunlukları olup olmadığına karar veren foobir yöntem gerçekten ise testForTriangle, testleriniz şöyle görünebilir:

// standard triangle with area >0
assertEqual(testForTriangle(2, 3, 4), true);

// degenerated triangle, length of two edges match the length of the third
assertEqual(testForTriangle(1, 2, 3), true);  

// no triangle
assertEqual(testForTriangle(1, 2, 4), false); 

// two sides equal
assertEqual(testForTriangle(2, 2, 3), true);

// all three sides equal
assertEqual(testForTriangle(4, 4, 4), true);

// degenerated triangle / point
assertEqual(testForTriangle(0, 0, 0), true);  

ve bunun gibi. Bunu iyileştirebilir ve yorumları assertEqualtest başarısız olduğunda görüntülenecek olan bir mesaj parametresine dönüştürebilirsiniz . Daha sonra bunu daha da geliştirebilir ve bunu veri güdümlü bir teste yeniden değerlendirebilirsiniz (test çerçeveniz destekliyorsa). Yine de, bu rakamları neden seçtiğinizi ve bireysel vaka ile test ettiğiniz çeşitli davranışları kodun içine bir not yazarsanız, kendinize bir iyilik yaparsınız.

Elbette, diğer fonksiyonlar için, parametreler için bireysel değerler daha önemli olabilir, bu nedenle fooparametrelerin anlamını nasıl ele alacağınız sorulduğunda olduğu gibi anlamsız bir fonksiyon adı kullanmak muhtemelen en iyi fikir değildir.

Neden sayılar yerine adlandırılmış Sabitler kullanmak istiyoruz?

1. KURU - 3 yerde değere ihtiyacım olursa, sadece bir kez tanımlamak istiyorum, böylece değişerse bir yerde değiştirebilirim.
2. Rakamlara anlam verin.

Her biri 3 Sayı (startBalance, faiz, yıl) çeşitliliği olan birkaç birim testi yazarsanız, değerleri sadece birim testine yerel değişkenler olarak paketlerdim. Ait oldukları en küçük kapsam.

testBigInterest()
  var startBalance = 10;
  var interestInPercent = 100
  var years = 2
  assert( calcCreditSum( startBalance, interestInPercent, years ) == 40 )

testSmallInterest()
  var startBalance = 50;
  var interestInPercent = .5
  var years = 1
  assert( calcCreditSum( startBalance, interestInPercent, years ) == 50.25 )

Adlandırılmış parametrelere izin veren bir dil kullanıyorsanız, bu elbette süper. Orada sadece ham metodları çağırırdım. Bu ifadeyi daha özlü hale getiren herhangi bir yeniden düzenleme yapmayı hayal edemiyorum:

testBigInterest()
  assert( calcCreditSum( startBalance:       10
                        ,interestInPercent: 100
                        ,years:               2 ) = 40 )

Veya test senaryolarını bir dizi veya Harita formatında tanımlamanıza izin verecek bir test Çerçevesi kullanın:

testcases = { {
                Name: "BigInterest"
               ,StartBalance:       10
               ,InterestInPercent: 100
               ,Years:               2
              }
             ,{ 
                Name: "SmallInterest"
               ,StartBalance:       50
               ,InterestInPercent:  .5
               ,Years:               1
              }
            }

... fakat bu durumda, sayıların aslında hiçbir anlamı yoktur.

Rakamlar bir yöntem çağırmak için kullanılıyor, bu yüzden kesinlikle yukarıdaki öncül yanlıştır. Sayıların ne olduğu umrunda değil , ama konunun dışında. Evet, bazı IDE sihirbazları tarafından numaraların ne için kullanıldığına karar verebilirsiniz, ancak sadece değer adlarını vermiş olsanız daha iyi olurdu - sadece parametrelere uysalar bile.

Bir test etmek isterseniz saf fonksiyonunu , sınır koşulları olmayan girdilerin bir sette o zaman neredeyse kesin bir üzerinde test etmek istiyorum sürü sınır koşulları olmayan (ve vardır) girdilerin setleri. Ve bana göre bu , fonksiyonu çağırmak için bir değerler tablosu ve bir döngü olması gerektiği anlamına gelir :

struct test_foo_values {
    int bar;
    int baz;
    int blurf;
    int expected;
};
const struct test_foo_values test_foo_with[] = {
   { 1, 2, 3, 17 },
   { 2, 4, 9, 34 },
   // ... many more here ...
};

for (size_t i = 0; i < ARRAY_SIZE(test_foo_with); i++) {
    const struct test_foo_values *c = test_foo_with[i];
    assertEqual(foo(c->bar, c->baz, c->blurf), c->expected);
}

Dannnno'nun cevabında önerildiği gibi araçlar , test edilecek değerler tablosunu oluşturmanıza yardımcı olabilir. bar, bazve Philipp'in cevabındablurf tartışıldığı gibi anlamlı isimlerle değiştirilmelidir .

(Burada tartışılabilir genel ilke: Sayılar her zaman "sihirli sayılar" dır, bunun yerine, sayılar veri olabilir . Sayılarınızı bir diziye, belki de bir kayıt dizisine koymak mantıklı olacaktır. Bunun tersine, elinizde veri bulunduğundan şüpheleniyorsanız, bir diziye yerleştirmeyi ve daha fazlasını edinmeyi düşünün.)

Testler üretim kodundan farklıdır ve en azından Spock'da yazılmış ünite testlerinde, kısa ve noktaya göre sihirli sabitleri kullanmakta sorunum yok.

Eğer bir test 5 satır uzunluğundaysa ve verilen / / / / sonrasında verilen şemaya uyuyorsa, bu gibi değerleri sabitlere çıkarmak kodun daha uzun sürmesini ve okunmasını zorlaştırır. Eğer mantık "Smith adında bir kullanıcı eklediğimde, Smith'in kullanıcı listesine geri döndüğü kullanıcıyı görüyorum" ise, "Smith" i sabitlemeye almanın bir anlamı yoktur.

Elbette, "verilen" (kurulum) blokta kullanılan değerleri "when" ve "then" bloklarında bulunan değerlerle kolayca eşleştirebiliyorsanız bu geçerlidir. Test kurulumunuz verinin kullanıldığı yerden ayrıldıysa (kodda), sabitleri kullanmak daha iyi olabilir. Ancak, testler kendi kendine yeten en iyiler olduğundan, kurulum genellikle kullanım yerine yakındır ve ilk durum geçerlidir, yani bu durumda sihirli sabitler oldukça kabul edilebilir.

Öncelikle, bir programcının yazdığı tüm otomatik testleri kapsayan “birim test” in sıkça kullanıldığını ve her testin ne denilmesi gerektiğini tartışmanın anlamsız olduğunu kabul edelim….

Yazılımın çok fazla girdi aldığı bir sistem üzerinde çalıştım ve diğer sayıları optimize ederken bazı kısıtlamaları yerine getirmek için bir “çözüm” geliştirdim. Doğru cevap yoktu, bu yüzden yazılım sadece makul bir cevap vermek zorunda kaldı.

Bunu bir başlangıç ​​noktası elde etmek için birçok rasgele sayı kullanarak, ardından sonucu iyileştirmek için bir “tepe tırmanıcı” kullanarak gerçekleştirdi. Bu birçok kez çalıştırıldı, en iyi sonucu alarak. Rasgele bir sayı üreteci ekilebilir, böylece her zaman aynı sayıları aynı sırada verir, bu nedenle test bir tohum hazırlarsa sonucun her çalışmada aynı olacağını biliyoruz.

Yukarıdakileri yapan çok sayıda test yaptık ve sonuçların aynı olup olmadığını kontrol ettik, bu bize sistemin yeniden yapılandırılması sırasında hatalı bir şekilde ne yaptığını değiştirmediğimizi söyledi . Bu durumun doğruluğu hakkında hiçbir şey söylemedi. sistemin o kısmı ne yaptı.

Bu testler, optimizasyon kodunda yapılan herhangi bir değişikliğin testleri kıracağından, ancak verileri daha önceden işleyen ve sonuçları sonradan işleyen çok daha büyük kodda bazı hatalar bulduğundan, bakımı maliyetlidir.

Veritabanını “alay ettiğimiz” için, bu sınamaları “birim sınamaları” olarak adlandırabilirsiniz, ancak “birim” oldukça büyüktü.

Çoğu zaman testsiz bir sistem üzerinde çalışırken, yukarıdaki gibi bir şey yaparsınız, böylece yeniden düzenlemenin çıktının değişmediğini onaylayabilirsiniz; Umarım yeni kod için daha iyi testler yazılmıştır!

Bu durumda, numaralara Magic Numbers yerine Rasgele Sayılar denmesi gerektiğini düşünüyorum ve satırı "rastgele test durumu" olarak yorumlayın.

Elbette, bazı Magic Numbers'lar da benzersiz "tutamaç" değerlerinde olduğu gibi isteğe bağlı olabilir (elbette adlandırılmış sabitlerle değiştirilmelidir), ancak "iki haftada bir artıklarda serbest bırakılmış bir Avrupa serisinin hava hızı" gibi önceden hesaplanmış sabitler de olabilir, Nümerik değer yorum veya faydalı bağlam olmadan takılı ise.

Kesin bir evet / hayır demek için girişimde bulunmayacağım, ama işte iyi olup olmadığına karar verirken kendinize sormanız gereken bazı sorular var.

1. Rakamlar bir şey ifade etmiyorsa, neden ilk etapta oradalar? Başka bir şeyle değiştirilebilir mi? Değer iddiaları yerine yöntem çağrılarına ve akışına dayalı doğrulama yapabilir misiniz? Mockito'nun verify(), aslında bir değer ortaya koymak yerine, nesnelerle alay etmek için belirli yöntem çağrılarının yapılıp yapılmadığını kontrol eden bir yöntem düşünün .

2. Sayılar bir şey ifade ediyorsa, uygun şekilde adlandırılmış değişkenlere atanmalıdırlar.

3. Numarayı Yazma 2olarak TWObelirli bağlamlarda yararlı ve diğer durumlarda, çok fazla değil olabilir.

   • Örneğin: assertEquals(TWO, half_of(FOUR))kodu okuyan birine mantıklı geliyor. Ne test ettiğiniz hemen bellidir.
   • Ancak, eğer sınavın buysa assertEquals(numCustomersInBank(BANK_1), TWO), bu o kadar mantıklı değil. Neden gelmez BANK_1iki müşteriler içeriyor? Ne için test ediyoruz?