Mevcut projem için bazı birim testleri yazmaya başladım. Bununla birlikte gerçekten bir deneyimim yok. Öncelikle tamamen "almak" istiyorum, bu yüzden şu anda ne IoC çerçevemi ne de alaycı bir kütüphane kullanıyorum.

Birim testlerinde nesnelerin kurucularına boş argümanlar sunarken yanlış bir şey olup olmadığını merak ediyordum. Bazı örnek kod vereyim:

public class CarRadio
{...}


public class Motor
{
    public void SetSpeed(float speed){...}
}


public class Car
{
    public Car(CarRadio carRadio, Motor motor){...}
}


public class SpeedLimit
{
    public bool IsViolatedBy(Car car){...}
}

Yine Bir Başka Araba Kodu Örneği (TM), yalnızca soru için önemli olan kısımlara indirgenmiştir. Şimdi böyle bir şey bir test yazdım:

public class SpeedLimitTest
{
    public void TestSpeedLimit()
    {
        Motor motor = new Motor();
        motor.SetSpeed(10f);
        Car car = new Car(null, motor);

        SpeedLimit speedLimit = new SpeedLimit();
        Assert.IsTrue(speedLimit.IsViolatedBy(car));
    }
}

Test iyi çalışıyor. SpeedLimitBir şey yapmak için bir Carile ihtiyacı var Motor. Hiç ilgilenmiyor CarRadio, bu yüzden boş verdim.

Tamamen oluşturulmadan doğru işlevsellik sağlayan bir nesnenin SRP veya kod kokusu ihlali olup olmadığını merak ediyorum . Bu dırdırcı hislerim var ama speedLimit.IsViolatedBy(motor)haklı çıkmıyor - hız limiti motor tarafından değil, araba tarafından ihlal ediliyor. Belki de ünite testleri ve çalışma kodları için farklı bir perspektife ihtiyacım var, çünkü amacım bütünün sadece bir bölümünü test etmektir.

Birim testlerinde null değerine sahip nesneler oluşturmak bir kod kokusu mu?

Yukarıdaki örnekte, a Carolmadan bir var olabilir CarRadio. Bu durumda, CarRadiobazen sadece bir sıfır boşuna geçmenin kabul edilebilir olmadığını söylemek zorunda kalacağımı, zorunlu olduğunu söyleyebilirim. Testlerinizin Carsınıfın uygulanmasının sağlam olduğundan ve hiçbir CarRadioşey olmadığında boş gösterici istisnaları oluşturmadığından emin olmanız gerekir .

Ancak, farklı bir örnek alalım - bir düşünelim SteeringWheel. Bir tane Carolması gerektiğini varsayalım SteeringWheel, ancak hız testi bunu gerçekten umursamıyor. Bu durumda nullu geçemem SteeringWheelçünkü bunun ardından Carsınıfı gitmek için tasarlanmadığı yerlere itiyor . Bu durumda, DefaultSteeringWheel(metafora devam etmek için) düz bir çizgide kilitli olan bir tür oluştururken daha iyi olursunuz .

Birim testlerinde null değerine sahip nesneler oluşturmak bir kod kokusu mu?

Evet. C2 kod kokusu tanımına dikkat edin : "Bir CodeSmell, bir şeyin yanlış olabileceğine, kesin değil bir ipucudur."

Test iyi çalışıyor. SpeedLimit'in işini yapabilmesi için Motorlu bir Arabaya ihtiyacı var. Bir CarRadio ile hiç ilgilenmiyor, bu yüzden boş verdim.

Eğer yapıcıya iletilen argümana speedLimit.IsViolatedBy(car)bağlı olmadığını göstermeye çalışıyorsanız CarRadio, daha sonra çağrılırsa testi geçemeyen bir testi iki katına sokarak bu kısıtlamayı açık hale getirmek için gelecekteki bakımcılar için daha net bir şekilde anlaşılır.

Daha muhtemel olduğu gibi, sadece CarRadiobu durumda kullanılmadığını bildiğiniz bir eseri yaratma çalışmalarını kendinizden kurtarmaya çalışıyorsanız , şunu fark etmelisiniz:

• bu bir kapsülleme ihlalidir ( CarRadiokullanılmayan gerçeğin teste sızmasına izin veriyorsunuz )
• Carbelirtmeden bir oluşturmak istediğiniz en az bir vaka keşfettinizCarRadio

Kodun size benzeyen bir kurucu istediğinizi söylemeye çalıştığından şüpheliyim.

public Car(IMotor motor) {...}

ve sonra o kurucu , hiçbir şeyin olmadığı gerçeğiyle ne yapılacağına karar verebilir.CarRadio

public Car(IMotor motor) {
    this(null, motor);
}

veya

public Car(IMotor motor) {
    this( new ICarRadio() {...} , motor);
}

veya

public Car(IMotor motor) {
    this( new DefaultRadio(), motor);
}

vb.

SpeedLimit'i test ederken boş bir şeye geçiyorsa. Testin "SpeedLimitTest" olarak adlandırıldığını ve tek Assert'in SpeedLimit yöntemini kontrol ettiğini görebilirsiniz.

Bu ikinci ve ilginç bir koku - SpeedLimit'i test etmek için, SpeedLimit'in kontrol ettiği tek şey hız olsa bile, bir telsizin etrafına bir otomobil yapmak zorundasınız .

Bu , tüm bir aracı talep etmek yerine , aracın uyguladığıSpeedLimit.isViolatedBy bir rol arabirimini kabul etmesi gereken bir ipucu olabilir .

interface IHaveSpeed {
    float speed();
}

class Car implements IHaveSpeed {...}

IHaveSpeedgerçekten berbat bir isim; umarım etki alanı dilinizde bir gelişme olur.

Bu arayüz yerinde olduğunda, testiniz SpeedLimitçok daha kolay olabilir

public void TestSpeedLimit()
{
    IHaveSpeed somethingTravelingQuickly = new IHaveSpeed {
        float speed() { return 10f; }
    }

    SpeedLimit speedLimit = new SpeedLimit();
    Assert.IsTrue(speedLimit.IsViolatedBy(somethingTravelingQuickly));
}

Birim testlerinde null değerine sahip nesneler oluşturmak bir kod kokusu mu?

Hayır

Bir şey değil. Aksine, eğer NULLbir argüman olarak kullanılabilir bir değerdir (bazı diller bir boş gösterici arasında geçen reddetmez yapıları olabilir), sen gerektiğini test edin.

Başka bir soru, geçerken ne olduğudur NULL. Fakat tam olarak bir birim testinin konusu budur: her olası giriş için tanımlanmış bir sonucun yapıldığından emin olmak . Ve NULL olan bir tarif edilen sonucu olmalı ve bunun için bir test olmalıdır, böylece bir potansiyel girdi.

Senin Araç Yani eğer sözde bir radyo olmadan constructable olmak, sen gerektiğini bunun için bir test yazmak. O değil ise ve sözde bir özel durum için, sen gerektiğini bunun için bir test yazmak.

Her iki şekilde de, evet gerektiğini için bir test yazmak NULL. Dışarıda bıraksanız bir kod kokusu olurdu. Bu, sihirli bir şekilde hatasız olacağını varsaydığınız test edilmemiş bir kod dalına sahip olduğunuz anlamına gelir.

Lütfen, test edilen kodunuzun geliştirilebileceği diğer cevapları kabul ettiğimi unutmayın. Bununla birlikte, geliştirilmiş kodun işaretçi parametreleri varsa, gelişmiş kod NULLiçin bile geçilmesi iyi bir testtir. NULLMotor olarak geçtiğimde neler olacağını göstermek için bir test yapmak isterdim . Bu bir kod kokusu değil, bir kod kokusunun tam tersi. Test ediyor.

Şahsen ben boşuna enjekte tereddüt ederdim. Aslında, ne zaman bir kurucuya bağımlılıklar enjekte ettiğimde, yaptığım ilk şeylerden biri, eğer bu enjeksiyonlar boşsa, ArgumentNullException değerini yükseltmektir. Bu sayede etrafımda düzinelerce boş denetime gerek kalmadan bunları sınıfımda güvenle kullanabilirim. İşte çok yaygın bir desen. Yapıcıda ayarlanan bağımlılıkların daha sonra null (veya başka bir şey) olarak ayarlanamayacağından emin olmak için salt okunur kullanımına dikkat edin:

class Car
{
   private readonly ICarRadio _carRadio;
   private readonly IMotor _motor;

   public Car(ICarRadio carRadio, IMotor motor)
   {
      if (carRadio == null)
         throw new ArgumentNullException(nameof(carRadio));

      if (motor == null)
         throw new ArgumentNullException(nameof(motor));

      _carRadio = carRadio;
      _motor = motor;
   }
}

Yukarıdakiler ile, belki boş çeklerimin beklendiği gibi çalıştığından emin olmak için boş değer enjekte ettiğim bir ya da iki tane bir test yapabilirim.

Bunu söyledikten sonra, iki şey yaptığınızda, bu bir sorun olmaz:

1. Program yerine sınıfları arabirimler için.
2. Boş değer yerine sahte bağımlılıkları enjekte etmek için sahte bir çerçeve kullanın (Cq için Moq gibi).

Öyleyse, örneğin;

interface ICarRadio
{
   bool Tune(float frequency);
}

interface Motor
{
   bool SetSpeed(float speed);
}

...
var car = new Car(new Moq<ICarRadio>().Object, new Moq<IMotor>().Object);

Moq kullanımıyla ilgili daha fazla ayrıntı burada bulunabilir .

Elbette, ilk önce alay etmeden anlamak istiyorsanız, arayüzleri kullandığınız sürece hala yapabilirsiniz. Basitçe aşağıdaki gibi sahte bir CarRadio ve Motor oluşturun ve bunları yerine enjekte edin:

class DummyCarRadio : ICarRadio
{
   ...
}
class DummyMotor : IMotor
{
   ...
}

...
var car = new Car(new DummyCarRadio(), new DummyMotor())

Sorun değil, eski kodu bir test donanımına sokmak için iyi bilinen bir bağımlılık kırma tekniğidir. (Bkz. Michael Feathers'ın “Eski Kod ile Etkili Çalışması”.)

Kokuyor mu? İyi...

Test kokusu yok. Test işini yapıyor. “Bu nesne boş olabilir ve test edilen kod hala doğru çalışıyor” şeklinde beyan ediyor.

Koku uygulamada. Bir yapıcı argümanı bildirerek, “ düzgün çalışması için bu sınıfın buna ihtiyacı var ” olduğunu beyan ediyorsunuz . Açıkçası, bu doğru değil. Gerçek olmayan herhangi bir şey biraz koklamak.

İlk prensiplere geri dönelim.

Birim testi, tek bir sınıfın bazı yönlerini test eder.

Ancak, diğer sınıfları parametre olarak alan yapıcılar veya yöntemler olacaktır. Bunlarla nasıl başa çıkacağınız durumdan duruma değişecektir ancak kurulum hedefe göre teğet oldukları için minimum düzeyde olmalıdır. NULL parametresini geçmenin tamamen geçerli olmadığı senaryolar olabilir - örneğin radyosu olmayan bir araba.

Ben sadece (araba teması devam etmek) ile başlamak yarış çizgisini test etmekte olduğumuzu, burada tahmin ediyorum, ancak olabilecek ayrıca herhangi defansif kodu ve istisna teslim mekanizmaları olarak çalışıp çalışmadığını kontrol etmek için diğer parametrelere NULL geçmek istiyorum gereklidir.

Çok uzak çok iyi. Ancak, NULL geçerli bir değer değilse . Eh, burada alay, taslak, aptal ve sahte bulanık dünyasındasın .

Bunların üstesinden gelmek biraz zor görünüyorsa, aslında potansiyel olarak kullanılmayacak bir değer olduğundan, Araba yapıcısında NULL değerini geçirerek bir kukla kullanıyorsunuzdur.

Çok hızlı bir şekilde netleşmesi gereken, potansiyel olarak birçok NULL işlemden geçirme ile kodunuzu vurmaya başlamış olmanızdır. Sınıf parametrelerini arayüzlerle değiştirirseniz, bunları işlemeyi çok daha kolay hale getiren alaycı ve DI vb. Yollarını açabilirsiniz.

Tasarımınıza bir göz atarak Car, bir kümeden ibaret olduğunu öneririm Features. Bir Özellik belki bir CarRadio, veya EntertainmentSystembir şey CarRadio, DvdPlayervb gibi şeylerden oluşabilir

Yani, en azından, Carbir dizi ile bir inşa etmek zorunda kalacaktı Features. EntertainmentSystemve CarRadioarabiriminin uygulayıcıları (Java, C # etc) public [I|i]nterface Featureolacaktır ve bu da Kompozit tasarım modelinin bir örneği olacaktır.

Bu nedenle, her zaman bir Carbirlikte inşa edersiniz Featuresve bir birim testi hiçbir zaman bir tane Carolmadan başlatmaz Features. BasicTestCarFeatureSetEn basit testiniz için gerekli olan asgari bir işlevsellik kümesi olan bir alaycı düşünebilirsiniz .

Sadece bazı düşünceler.

John