도메인 개체 생성을 테스트하기위한 단위 테스트

다음과 같은 단위 테스트가 있습니다.

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

Person 객체가 여기에 생성되었다고 주장합니다. 즉 유효성 검사가 실패하지 않습니다. 예를 들어, Guid가 null이거나 생년월일이 01/01/1900 이전 인 경우 유효성 검사가 실패하고 예외가 발생합니다 (테스트가 실패 함을 의미 함).

생성자는 다음과 같습니다.

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;
    }

이것은 테스트에 좋은 아이디어입니까?

참고 : 도메인 모델을 테스트하는 고전주의 접근법을 따르고 있습니다.

이것은 유효한 테스트이며 (과도하지만 지나치게) 생성자 논리를 테스트하기 위해 때때로 수행하지만, Laiv가 의견에서 언급했듯이 이유를 스스로에게 문의해야합니다.

생성자가 다음과 같은 경우 :

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

던지는 여부를 테스트하는 데 많은 요점이 있습니까? 매개 변수가 올바르게 할당되었는지 여부는 이해할 수 있지만 테스트는 과도합니다.

그러나 테스트가 다음과 같은 경우 :

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;
}

그런 다음 코드에서 실제로 예외를 던지면서 테스트가 더 관련성이 높아집니다.

한 가지 말하지만 일반적으로 생성자에 많은 논리를 갖는 것은 나쁜 습관입니다. 기본 유효성 검사 (위의 null / default 검사와 같은)는 정상입니다. 그러나 데이터베이스에 연결하고 누군가의 데이터를로드하는 경우 코드가 실제로 냄새를 맡기 시작하는 곳입니다 ...

이 때문에 생성자가 테스트할만한 가치가 있다면 (논리가 많기 때문에) 다른 것이 잘못되었을 수 있습니다.

비즈니스 로직 계층에서이 클래스를 다루는 다른 테스트가있을 것입니다. 생성자와 변수 할당은 거의 확실하게 이러한 테스트에서 완전한 적용 범위를 갖습니다. 따라서 생성자에 대해 특정 테스트를 추가하는 것은 의미가 없습니다. 그러나 흑인과 백인은 아무것도 없으며 코드를 검토하는 경우 이러한 테스트에 대해 아무것도하지 않습니다. 그러나 솔루션의 다른 곳에서 테스트보다 높은 가치를 추가하는지 여부는 의문입니다.

귀하의 예에서 :

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;
    }

유효성 검사를 수행 할뿐만 아니라 기본 생성자를 호출합니다. 나에게 이것은 생성자 / 유효성 검사 논리가 이제 두 클래스로 나뉘어 가시성을 줄이고 예기치 않은 변경의 위험을 증가시키기 때문에 이러한 테스트를해야 할 더 많은 이유를 제공합니다.

TLDR

이러한 테스트에는 약간의 가치가 있지만 유효성 검사 / 할당 논리는 솔루션의 다른 테스트에서 다룰 수 있습니다. 이러한 생성자에 많은 테스트가 필요한 논리가 많으면 거기에 숨어있는 불쾌한 코드 냄새가 나옵니다.

이미 좋은 대답이지만, 한 가지 더 언급 할 가치가 있다고 생각합니다.

"책으로" TDD를 수행 할 때는 생성자가 구현되기 전에 먼저 생성자를 호출하는 테스트를 작성해야합니다. 이 테스트는 생성자의 구현 내에 유효성 검사 논리가 0이 아니더라도 실제로 제시 한 것과 비슷할 수 있습니다.

또한 TDD의 경우 먼저 다른 테스트를 작성해야합니다.

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

DateTime(1900,01,01)생성자에 확인을 추가 하기 전에 .

TDD 컨텍스트에서 표시된 테스트는 완벽하게 이해됩니다.