การทดสอบหน่วยเพื่อทดสอบการสร้างวัตถุโดเมน

ฉันมีการทดสอบหน่วยซึ่งมีลักษณะดังนี้:

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

ฉันยืนยันว่ามีการสร้างวัตถุบุคคลที่นี่เช่นการตรวจสอบความถูกต้องจะไม่ล้มเหลว ตัวอย่างเช่นหาก Guid เป็นโมฆะหรือวันเดือนปีเกิดเร็วกว่า 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;
    }

นี่เป็นความคิดที่ดีสำหรับการทดสอบหรือไม่?

หมายเหตุ : ฉันกำลังปฏิบัติตามวิธีการแบบคลาสสิคเพื่อทดสอบหน่วยโดเมนแบบจำลองหากถือครองใด ๆ

นี่คือการทดสอบที่ถูกต้อง (แต่ค่อนข้าง overzealous) และบางครั้งฉันทำเพื่อทดสอบตรรกะตัวสร้าง แต่เป็น Laiv ที่กล่าวถึงในความคิดเห็นที่คุณควรถามตัวเองว่าทำไม

หากคอนสตรัคของคุณมีลักษณะเช่นนี้:

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

มีจุดมากในการทดสอบว่ามันพ่น? ฉันสามารถเข้าใจพารามิเตอร์ได้หรือไม่ แต่การทดสอบของคุณค่อนข้าง overkill

อย่างไรก็ตามหากการทดสอบของคุณทำสิ่งนี้:

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 การทดสอบที่แสดงนั้นเหมาะสมอย่างสมบูรณ์