Etki Alanı Nesnesinin oluşturulmasını test etmek için Birim Testi

Şöyle bir Birim Testi var:

[Test]
public void Should_create_person()
{
     Assert.DoesNotThrow(() => new Person(Guid.NewGuid(), new DateTime(1972, 01, 01));
}

Burada bir Person nesnesi oluşturulduğunu, yani doğrulama başarısız olduğunu iddia ediyorum. Örneğin, Rehber null olursa veya doğum tarihi 01/01/1900'den önce ise, doğrulama başarısız olur ve bir istisna atılır (test başarısız olur).

Yapıcı şöyle görünür:

public Person(Id id, DateTime dateOfBirth) :
        base(id)
    {
        if (dateOfBirth == null)
            throw new ArgumentNullException("Date of Birth");
        elseif (dateOfBith < new DateTime(1900,01,01)
            throw new ArgumentException("Date of Birth");
        DateOfBirth = dateOfBirth;
    }

Bu bir test için iyi bir fikir mi?

Not : Etki Alan Modelinin Birim Testi için herhangi bir etkisi varsa Klasikçi bir yaklaşımı izliyorum.

Bu geçerli bir testtir (oldukça aşırı olsa da) ve bazen yapıcı mantığını test etmek için yapıyorum, ancak Laiv'in yorumlarda belirttiği gibi kendinize nedenini sormalısınız.

Yapımcınız şöyle görünüyorsa:

public Person(Guid guid, DateTime dob)
{
  this.Guid = guid;
  this.Dob = dob;
}

Test edip etmediğini test etmenin çok anlamı var mı? Parametrelerin doğru atanıp atanmadığını anlayabiliyorum, ancak testiniz oldukça fazla.

Ancak, testiniz böyle bir şey yaparsa:

public Person(Guid guid, DateTime dob)
{
  if(guid == default(Guid)) throw new ArgumentException("Guid is invalid");
  if(dob == default(DateTime)) throw new ArgumentException("Dob is invalid");

  this.Guid = guid;
  this.Dob = dob;
}

Daha sonra testiniz daha alakalı hale gelir (kodda bir yere istisnalar attığınız için).

Söyleyeceğim bir şey, genellikle yapıcıda çok fazla mantık olması kötü bir uygulamadır. Temel doğrulama (yukarıda yaptığım boş / varsayılan kontroller gibi) tamam. Ancak veritabanlarına bağlanıyor ve birinin verilerini yüklüyorsanız, kod gerçekten kokmaya başlar.

Bu nedenle, kurucunuz test etmeye değerse (çünkü çok fazla mantık var) o zaman başka bir şey yanlış olabilir.

İş mantığı katmanlarında, kurucularında ve değişken atamalarında bu sınıfı kapsayan diğer testleriniz neredeyse kesinlikle bu testlerden tam olarak ele alınacaktır. Bu nedenle, özellikle kurucu için spesifik testler eklemek anlamsız olabilir. Ancak, hiçbir şey siyah beyaz değildir ve kodları inceliyor olsaydım bu testlere karşı hiçbir şeyim olmazdı - ancak çözümünüzün başka bir yerinde testlerin üstüne ve ötesine çok fazla değer ekleyip eklemediklerini sorgulayacağım.

Örneğinizde:

public Person(Id id, DateTime dateOfBirth) :
        base(id)
    {
        if (dateOfBirth == null)
            throw new ArgumentNullException("Date of Birth");
        elseif (dateOfBith < new DateTime(1900,01,01)
            throw new ArgumentException("Date of Birth");
        DateOfBirth = dateOfBirth;
    }

Sadece doğrulama yapmıyorsunuz, aynı zamanda bir temel kurucu da diyorsunuz. Benim için bu, bu testleri yaptırmak için daha fazla neden sunuyor çünkü kurucu / validasyon mantığı şimdi görünürlüğü azaltan ve beklenmedik değişiklik riskini artıran iki sınıfa ayrılıyor.

TLDR

Bu testlerin bir değeri vardır, ancak doğrulama / atama mantığının çözümünüzdeki diğer testler tarafından kapsanması muhtemeldir. Bu kurucularda önemli testler gerektiren bir sürü mantık varsa, o zaman bana orada gizli bir koku kokusu olduğunu gösteriyor.

Zaten burada iyi bir cevap, ama bence ek bir şeyden bahsetmeye değer.

TDD'yi "kitap tarafından" yaparken , kurucu uygulanmadan önce bile kurucuyu çağıran bir test yazmanız gerekir. Bu test, kurucunun uygulamasında sıfır doğrulama mantığı olsa bile, sunduğunuz teste benzeyebilir.

Ayrıca TDD için önce bir başka test yazılması gerektiğini unutmayın.

  Assert.Throws<ArgumentException>(() => new Person(Guid.NewGuid(), 
        new DateTime(1572, 01, 01));

yapıcıya onay eklemeden önceDateTime(1900,01,01) .

TDD bağlamında, gösterilen test mükemmel bir anlam ifade eder.