Kiểm tra đơn vị để kiểm tra việc tạo Đối tượng Miền

Tôi có một bài kiểm tra đơn vị, trông như thế này:

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

Tôi khẳng định rằng một đối tượng Person được tạo ở đây tức là xác nhận không thất bại. Ví dụ: nếu Guid là null hoặc ngày sinh sớm hơn 01/01/1900, thì xác thực sẽ thất bại và một ngoại lệ sẽ bị ném (có nghĩa là thử nghiệm thất bại).

Hàm tạo trông như thế này:

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

Đây có phải là một ý tưởng tốt cho một bài kiểm tra?

Lưu ý : Tôi đang theo cách tiếp cận Cổ điển để Kiểm tra Đơn vị Mô hình Miền nếu điều đó có bất kỳ ảnh hưởng nào.

Đây là một thử nghiệm hợp lệ (mặc dù khá hăng hái) và đôi khi tôi làm nó để kiểm tra logic của nhà xây dựng, tuy nhiên như Laiv đã đề cập trong các ý kiến ​​bạn nên tự hỏi tại sao.

Nếu nhà xây dựng của bạn trông như thế này:

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

Có rất nhiều điểm trong thử nghiệm cho dù nó ném? Cho dù các tham số được gán chính xác tôi có thể hiểu nhưng kiểm tra của bạn là quá mức cần thiết.

Tuy nhiên, nếu thử nghiệm của bạn làm một cái gì đó như thế này:

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

Sau đó, bài kiểm tra của bạn trở nên phù hợp hơn (vì bạn thực sự đang ném ngoại lệ ở đâu đó trong mã).

Một điều tôi muốn nói, nói chung, đó là cách thực hành tồi để có nhiều logic trong công cụ xây dựng của bạn. Xác nhận cơ bản (như kiểm tra null / mặc định tôi đang làm ở trên) đều ổn. Nhưng nếu bạn đang kết nối với cơ sở dữ liệu và tải dữ liệu của ai đó thì đó là nơi mã bắt đầu thực sự có mùi ...

Bởi vì điều này, nếu nhà xây dựng của bạn đáng để thử nghiệm (vì có rất nhiều logic sẽ xảy ra) thì có thể có điều gì đó không ổn.

Bạn gần như chắc chắn sẽ có các thử nghiệm khác bao gồm lớp này trong các lớp logic nghiệp vụ, các hàm tạo và các phép gán biến gần như chắc chắn sẽ có được phạm vi bảo hiểm hoàn chỉnh từ các thử nghiệm này. Do đó, có thể vô nghĩa khi thêm các thử nghiệm cụ thể cụ thể cho hàm tạo. Tuy nhiên, không có gì là đen trắng và tôi sẽ không có gì chống lại các thử nghiệm này nếu tôi đang xem xét mã chúng - nhưng tôi đặt câu hỏi liệu chúng có thêm nhiều giá trị ở trên và ngoài các thử nghiệm ở nơi khác trong giải pháp của bạn không.

Trong ví dụ của bạn:

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

Bạn không chỉ thực hiện xác nhận, mà bạn còn gọi một nhà xây dựng cơ sở. Đối với tôi, điều này cung cấp thêm lý do để thực hiện các thử nghiệm này vì chúng có logic xây dựng / xác thực hiện được chia thành hai lớp làm giảm khả năng hiển thị và tăng nguy cơ thay đổi bất ngờ.

TLD

Có một số giá trị cho các thử nghiệm này, tuy nhiên logic xác thực / gán có thể sẽ được bao phủ bởi các thử nghiệm khác trong giải pháp của bạn. Nếu có rất nhiều logic trong các hàm tạo này yêu cầu thử nghiệm quan trọng thì nó gợi ý cho tôi rằng có một mùi mã khó chịu ẩn nấp trong đó.

Đã có một câu trả lời tốt ở đây, nhưng tôi nghĩ một điều nữa là đáng nói.

Khi thực hiện TDD "bằng cuốn sách", trước tiên người ta cần viết một bài kiểm tra để gọi hàm tạo, ngay cả trước khi hàm tạo được triển khai. Thử nghiệm đó thực sự có thể trông giống như thử nghiệm mà bạn đã trình bày, ngay cả khi sẽ không có logic xác thực bằng không bên trong triển khai của nhà xây dựng.

Cũng lưu ý rằng đối với TDD, trước tiên bạn nên viết một bài kiểm tra khác như

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

trước khi thêm kiểm tra cho DateTime(1900,01,01)hàm tạo.

Trong bối cảnh TDD, thử nghiệm hiển thị có ý nghĩa hoàn hảo.