Тест блоку для перевірки створення об’єкта домену

У мене є модульний тест, який виглядає приблизно так:

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

Я стверджую, що тут створюється об'єкт Person, тобто перевірка не проходить. Наприклад, якщо Посібник є недійсним або дата народження є раніше 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;
    }

Це хороша ідея для тесту?

Примітка . Я дотримуюсь класицистичного підходу до тестування одиничної моделі домену, якщо це має якесь значення.

Це дійсний тест (хоч і досить надурливий), і я іноді роблю це для перевірки логіки конструктора, проте, як згадував Лаїв у коментарях, ви повинні запитати себе, чому.

Якщо ваш конструктор виглядає так:

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

Тоді ваш тест стає більш релевантним (оскільки ви насправді кидаєте винятки десь у коді).

Я б сказав одне, загалом це погана практика - мати багато логіки у вашому конструкторі. Базова перевірка (як, наприклад, перевірка на нуль / за замовчуванням, яку я роблю вище) нормальна. Але якщо ви підключаєтесь до баз даних і завантажуєте чиїсь дані, то тут код починає насправді пахнути ...

Через це, якщо ваш конструктор вартий тестування (тому що логічно багато), можливо, щось інше не так.

Ви майже напевно будете мати інші тести, що охоплюють цей клас у шарах ділової логіки, конструктори та змінні завдання майже напевно отримають повне висвітлення цих тестів. Тому, можливо, безглуздо додавати конкретні тести спеціально для конструктора. Однак, нічого не є чорно-білим, і я б нічого не мав проти цих тестів, якби я їх переглядав, - але я б запитав, чи додають вони великої цінності вище та поза тестами в іншому місці вашого рішення.

У вашому прикладі:

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 "за книгою", потрібно спочатку написати тест, який викликає конструктор, ще до того, як конструктор буде реалізований. Цей тест насправді може виглядати як представлений вами, навіть якщо в реалізації конструктора буде логіка нульової перевірки.

Зауважте також, що для TDD слід спочатку написати ще один тест

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

перед тим як додати чек для DateTime(1900,01,01)конструктора.

У контексті TDD показаний тест має ідеальний сенс.