ตกลงหรือไม่ที่จะมีการยืนยันหลายชุดในการทดสอบหน่วยเดียว?

ในความคิดเห็นต่อโพสต์ที่ยอดเยี่ยมนี้ Roy Osherove ได้กล่าวถึงโครงการOAPTที่ออกแบบมาเพื่อใช้ในการทดสอบแต่ละครั้งในการทดสอบครั้งเดียว

ต่อไปนี้เป็นลายลักษณ์อักษรในโฮมเพจของโครงการ:

การทดสอบหน่วยที่เหมาะสมควรล้มเหลวด้วยเหตุผลเดียวนั่นคือเหตุผลที่คุณควรใช้หนึ่งยืนยันต่อการทดสอบหน่วย

และรอยยังเขียนความคิดเห็น:

แนวทางของฉันมักจะให้คุณทดสอบหนึ่งแนวคิดเชิงตรรกะต่อการทดสอบ คุณสามารถมีหลายอ้างในเดียวกัน วัตถุ พวกเขามักจะเป็นแนวคิดเดียวกันที่ถูกทดสอบ

ฉันคิดว่ามีบางกรณีที่จำเป็นต้องมีการยืนยันหลายครั้ง (เช่นGuard Assertion ) แต่โดยทั่วไปฉันพยายามหลีกเลี่ยงสิ่งนี้ ความคิดเห็นของคุณคืออะไร? โปรดให้เป็นตัวอย่างที่โลกแห่งความจริงที่หลายอ้างจริงๆจำเป็น

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

ต้องบอกว่าฉันจะบอกว่าบางทีครึ่งหนึ่งของการทดสอบของฉันจริงมีเพียงหนึ่งยืนยัน ฉันคิดว่ามันจะกลายเป็นเพียงรหัส (ทดสอบ) กลิ่นเมื่อคุณมีประมาณห้าหรือมากกว่ายืนยันในการทดสอบของคุณ

คุณจะแก้ปัญหาหลายชุดได้อย่างไร

การทดสอบควรล้มเหลวด้วยเหตุผลเดียวเท่านั้น แต่นั่นไม่ได้หมายความว่าควรมีเพียงหนึ่งAssertข้อความเท่านั้น IMHO มันสำคัญกว่าที่จะถือเป็นรูปแบบ "การจัดเรียงการกระทำการยืนยัน "

กุญแจสำคัญคือคุณมีการกระทำเดียวเท่านั้นจากนั้นคุณตรวจสอบผลลัพธ์ของการกระทำนั้นโดยใช้การยืนยัน แต่มันก็คือ "จัดการ, กระทำ, ยืนยัน, สิ้นสุดการทดสอบ " หากคุณถูกล่อลวงให้ทำการทดสอบต่อไปโดยทำการกระทำอื่นและยืนยันเพิ่มเติมในภายหลังให้ทำการทดสอบแยกต่างหากแทน

ฉันยินดีที่ได้เห็นข้อความยืนยันหลายข้อความที่เป็นส่วนหนึ่งของการทดสอบการกระทำเดียวกัน เช่น

[Test]
public void ValueIsInRange()
{
  int value = GetValueToTest();

  Assert.That(value, Is.GreaterThan(10), "value is too small");
  Assert.That(value, Is.LessThan(100), "value is too large");
} 

หรือ

[Test]
public void ListContainsOneValue()
{
  var list = GetListOf(1);

  Assert.That(list, Is.Not.Null, "List is null");
  Assert.That(list.Count, Is.EqualTo(1), "Should have one item in list");
  Assert.That(list[0], Is.Not.Null, "Item is null");
} 

คุณสามารถรวมเหล่านี้เป็นหนึ่งยืนยัน แต่ที่เป็นสิ่งที่แตกต่างจากการยืนยันว่าคุณควรหรือต้อง ไม่มีการปรับปรุงจากการรวมเข้าด้วยกัน

เช่นคนแรกอาจเป็น

Assert.IsTrue((10 < value) && (value < 100), "Value out of range"); 

แต่นี่ไม่ใช่เรื่องที่ดีกว่า - ข้อความแสดงข้อผิดพลาดออกมานั้นมีความเฉพาะเจาะจงน้อยกว่าและไม่มีข้อได้เปรียบอื่นใด ฉันแน่ใจว่าคุณสามารถนึกถึงตัวอย่างอื่น ๆ ที่รวมสองหรือสาม (หรือมากกว่า) เข้าไว้ในเงื่อนไขบูลีนขนาดใหญ่ทำให้ยากต่อการอ่านยากที่จะแก้ไขและยากที่จะหาสาเหตุที่มันล้มเหลว ทำไมทำเช่นนี้เพียงเพื่อประโยชน์ของกฎ?

หมายเหตุ : รหัสที่ฉันเขียนที่นี่คือ C # กับ NUnit แต่หลักการจะเก็บไว้กับภาษาและกรอบงานอื่น ๆ ไวยากรณ์อาจคล้ายกันมาก

ฉันไม่เคยคิดว่าการยืนยันมากกว่าหนึ่งเป็นสิ่งที่ไม่ดี

ฉันทำมันตลอดเวลา:

public void ToPredicateTest()
{
    ResultField rf = new ResultField(ResultFieldType.Measurement, "name", 100);
    Predicate<ResultField> p = (new ConditionBuilder()).LessThanConst(400)
                                                       .Or()
                                                       .OpenParenthesis()
                                                       .GreaterThanConst(500)
                                                       .And()
                                                       .LessThanConst(1000)
                                                       .And().Not()
                                                       .EqualsConst(666)
                                                       .CloseParenthesis()
                                                       .ToPredicate();
    Assert.IsTrue(p(ResultField.FillResult(rf, 399)));
    Assert.IsTrue(p(ResultField.FillResult(rf, 567)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 400)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 666)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 1001)));

    Predicate<ResultField> p2 = (new ConditionBuilder()).EqualsConst(true).ToPredicate();

    Assert.IsTrue(p2(new ResultField(ResultFieldType.Confirmation, "Is True", true)));
    Assert.IsFalse(p2(new ResultField(ResultFieldType.Confirmation, "Is False", false)));
}

ที่นี่ฉันใช้การยืนยันหลายครั้งเพื่อให้แน่ใจว่าเงื่อนไขที่ซับซ้อนสามารถเปลี่ยนเป็นเพรดิเคตที่คาดไว้

ฉันทำการทดสอบเพียงหน่วยเดียว ( ToPredicateวิธีการ) แต่ฉันครอบคลุมทุกอย่างที่ฉันสามารถคิดถึงได้ในการทดสอบ

เมื่อฉันใช้การทดสอบหน่วยเพื่อตรวจสอบพฤติกรรมระดับสูงฉันใส่การยืนยันหลายอย่างในการทดสอบครั้งเดียว นี่คือการทดสอบที่ฉันใช้จริงสำหรับรหัสแจ้งเตือนฉุกเฉินบางอย่าง รหัสที่รันก่อนการทดสอบทำให้ระบบอยู่ในสถานะที่หากตัวประมวลผลหลักทำงาน, สัญญาณเตือนจะถูกส่ง

@Test
public void testAlarmSent() {
    assertAllUnitsAvailable();
    assertNewAlarmMessages(0);

    pulseMainProcessor();

    assertAllUnitsAlerting();
    assertAllNotificationsSent();
    assertAllNotificationsUnclosed();
    assertNewAlarmMessages(1);
}

มันแสดงให้เห็นถึงเงื่อนไขที่จำเป็นต้องมีอยู่ในทุกขั้นตอนในกระบวนการเพื่อให้ฉันมั่นใจว่ารหัสทำงานตามที่ฉันคาดหวัง หากการยืนยันครั้งเดียวล้มเหลวฉันไม่สนใจว่าสิ่งที่เหลืออยู่จะไม่ถูกเรียกใช้ เนื่องจากสถานะของระบบไม่ถูกต้องอีกต่อไปการยืนยันที่ตามมาเหล่านั้นจะไม่บอกสิ่งที่มีค่า * ถ้าassertAllUnitsAlerting()ล้มเหลวฉันจะไม่ทราบว่าอะไรที่จะทำให้assertAllNotificationSent()สำเร็จหรือล้มเหลวจนกว่าฉันจะตัดสินว่าอะไรเป็นสาเหตุของข้อผิดพลาดก่อนหน้า และแก้ไขให้ถูกต้อง

(* - โอเคพวกเขาอาจมีประโยชน์ในการแก้ไขข้อบกพร่อง แต่ข้อมูลที่สำคัญที่สุดที่การทดสอบล้มเหลวได้รับแล้ว)

อีกเหตุผลหนึ่งที่ฉันคิดว่าการยืนยันหลายวิธีในหนึ่งวิธีนั้นไม่ใช่สิ่งเลวร้ายที่อธิบายไว้ในรหัสต่อไปนี้:

class Service {
    Result process();
}

class Result {
    Inner inner;
}

class Inner {
    int number;
}

ในการทดสอบของฉันฉันต้องการทดสอบว่าservice.process()คืนค่าตัวเลขที่ถูกต้องในInnerคลาสอินสแตนซ์

แทนที่จะทดสอบ ...

@Test
public void test() {
    Result res = service.process();
    if ( res != null && res.getInner() != null ) Assert.assertEquals( ..., res.getInner() );
}

ฉันกำลังทำ

@Test
public void test() {
    Result res = service.process();
    Assert.notNull(res);
    Assert.notNull(res.getInner());
    Assert.assertEquals( ..., res.getInner() );
}

ฉันคิดว่ามีหลายกรณีที่การเขียนข้อความยืนยันหลายชุดใช้ได้ภายในกฎที่การทดสอบควรล้มเหลวด้วยเหตุผลเดียวเท่านั้น

ตัวอย่างเช่นสมมติว่าฟังก์ชันแยกวิเคราะห์สตริงวันที่:

function testParseValidDateYMD() {
    var date = Date.parse("2016-01-02");

    Assert.That(date.Year).Equals(2016);
    Assert.That(date.Month).Equals(1);
    Assert.That(date.Day).Equals(0);
}

หากการทดสอบล้มเหลวนั่นเป็นเพราะเหตุผลหนึ่งข้อการวิเคราะห์คำไม่ถูกต้อง หากคุณยืนยันว่าการทดสอบนี้อาจล้มเหลวด้วยเหตุผลสามประการที่แตกต่างกันคุณจะได้รับผลการทดสอบที่แย่เกินไปในคำจำกัดความของคุณว่า "เหตุผลหนึ่งข้อ"

ฉันไม่รู้สถานการณ์ใด ๆ ซึ่งเป็นความคิดที่ดีที่จะมีการยืนยันที่หลากหลายภายในวิธี [Test] เหตุผลหลักที่ผู้คนต้องการมีการยืนยันหลายครั้งก็คือพวกเขาพยายามที่จะมีคลาส [TestFixture] หนึ่งชั้นสำหรับแต่ละชั้นที่กำลังทดสอบ แต่คุณสามารถแบ่งการทดสอบออกเป็นคลาส [TestFixture] เพิ่มเติม สิ่งนี้ช่วยให้คุณเห็นหลายวิธีที่โค้ดอาจไม่ตอบสนองในแบบที่คุณคาดไว้แทนที่จะเป็นเพียงวิธีที่การยืนยันแรกล้มเหลว วิธีที่คุณจะบรรลุเป้าหมายนี้คือคุณมีอย่างน้อยหนึ่งไดเร็กทอรีต่อคลาสที่ถูกทดสอบพร้อมกับคลาส [TestFixture] จำนวนมากภายใน แต่ละคลาส [TestFixture] จะได้รับการตั้งชื่อตามสถานะเฉพาะของวัตถุที่คุณจะทำการทดสอบ เมธอด [SetUp] จะทำให้วัตถุอยู่ในสถานะที่อธิบายโดยชื่อคลาส จากนั้นคุณจะมีวิธี [ทดสอบ] หลายวิธีในการแยกแยะสิ่งต่าง ๆ ที่คุณคาดหวังว่าจะเป็นจริงเนื่องจากสถานะปัจจุบันของวัตถุ เมธอด [Test] แต่ละชื่อจะตั้งชื่อตามสิ่งที่มันเป็นการยืนยันยกเว้นบางทีมันอาจถูกตั้งชื่อตามแนวคิดแทนที่จะเป็นเพียงการอ่านโค้ดภาษาอังกฤษ จากนั้นการใช้เมธอด [Test] แต่ละตัวจะต้องมีโค้ดเพียงบรรทัดเดียวเท่านั้น ข้อดีอีกประการของวิธีการนี้คือทำให้การทดสอบสามารถอ่านได้อย่างชัดเจนเนื่องจากมันชัดเจนว่าคุณกำลังทดสอบอะไรและสิ่งที่คุณคาดหวังเพียงแค่ดูชื่อคลาสและเมธอด สิ่งนี้จะขยายขนาดได้ดีขึ้นเมื่อคุณเริ่มตระหนักถึงกรณีเล็ก ๆ น้อย ๆ ทั้งหมดที่คุณต้องการทดสอบและเมื่อคุณพบข้อบกพร่อง ยกเว้นบางทีมันอาจถูกตั้งชื่อตามแนวคิดแทนที่จะเป็นเพียงการอ่านภาษาอังกฤษของรหัส จากนั้นการใช้เมธอด [Test] แต่ละตัวจะต้องมีโค้ดเพียงบรรทัดเดียวเท่านั้น ข้อดีอีกประการของวิธีการนี้คือทำให้การทดสอบสามารถอ่านได้อย่างชัดเจนเนื่องจากมันค่อนข้างชัดเจนว่าคุณกำลังทดสอบอะไรและสิ่งที่คุณคาดหวังเพียงแค่ดูชื่อคลาสและเมธอด สิ่งนี้จะขยายขนาดได้ดีขึ้นเมื่อคุณเริ่มตระหนักถึงกรณีเล็ก ๆ น้อย ๆ ทั้งหมดที่คุณต้องการทดสอบและเมื่อคุณพบข้อบกพร่อง ยกเว้นบางทีมันอาจถูกตั้งชื่อตามแนวคิดแทนที่จะเป็นเพียงการอ่านภาษาอังกฤษของรหัส จากนั้นการใช้เมธอด [Test] แต่ละตัวจะต้องมีโค้ดเพียงบรรทัดเดียวเท่านั้น ข้อดีอีกประการของวิธีการนี้คือทำให้การทดสอบสามารถอ่านได้อย่างชัดเจนเนื่องจากมันชัดเจนว่าคุณกำลังทดสอบอะไรและสิ่งที่คุณคาดหวังเพียงแค่ดูชื่อคลาสและเมธอด สิ่งนี้จะขยายขนาดได้ดีขึ้นเมื่อคุณเริ่มตระหนักถึงกรณีเล็ก ๆ น้อย ๆ ทั้งหมดที่คุณต้องการทดสอบและเมื่อคุณพบข้อบกพร่อง และสิ่งที่คุณคาดหวังเพียงแค่ดูชื่อคลาสและเมธอด สิ่งนี้จะขยายขนาดได้ดีขึ้นเมื่อคุณเริ่มตระหนักถึงกรณีเล็ก ๆ น้อย ๆ ทั้งหมดที่คุณต้องการทดสอบและเมื่อคุณพบข้อบกพร่อง และสิ่งที่คุณคาดหวังเพียงแค่ดูชื่อคลาสและเมธอด สิ่งนี้จะขยายขนาดได้ดีขึ้นเมื่อคุณเริ่มตระหนักถึงกรณีเล็ก ๆ น้อย ๆ ทั้งหมดที่คุณต้องการทดสอบและเมื่อคุณพบข้อบกพร่อง

โดยทั่วไปนี่หมายความว่าบรรทัดสุดท้ายของโค้ดภายในเมธอด [SetUp] ควรเก็บค่าคุณสมบัติหรือค่าส่งคืนในตัวแปรอินสแตนซ์ส่วนตัวของ [TestFixture] จากนั้นคุณอาจยืนยันสิ่งต่าง ๆ มากมายเกี่ยวกับตัวแปรอินสแตนซ์นี้จากวิธี [ทดสอบ] ที่แตกต่างกัน คุณอาจยืนยันถึงคุณสมบัติที่แตกต่างกันของวัตถุภายใต้การทดสอบที่ถูกตั้งค่าเป็นตอนนี้ว่ามันอยู่ในสถานะที่ต้องการ

บางครั้งคุณจำเป็นต้องทำการยืนยันตามวิธีที่คุณได้รับวัตถุภายใต้การทดสอบเข้าสู่สถานะที่ต้องการเพื่อให้แน่ใจว่าคุณไม่ได้เลอะก่อนที่จะรับวัตถุในสถานะที่ต้องการ ในกรณีนั้นการยืนยันพิเศษเหล่านั้นควรปรากฏในวิธี [ตั้งค่า] หากมีสิ่งใดผิดพลาดภายในวิธี [SetUp] มันจะเห็นได้ชัดว่ามีบางอย่างผิดปกติกับการทดสอบก่อนที่วัตถุจะเข้าสู่สถานะที่คุณต้องการทดสอบ

ปัญหาอื่นที่คุณอาจพบคือคุณอาจทดสอบข้อยกเว้นที่คุณคาดว่าจะถูกโยนทิ้ง สิ่งนี้สามารถล่อลวงให้คุณไม่ติดตามโมเดลด้านบน อย่างไรก็ตามยังสามารถทำได้โดยการจับข้อยกเว้นภายในวิธี [SetUp] และเก็บไว้ในตัวแปรอินสแตนซ์ สิ่งนี้จะช่วยให้คุณสามารถยืนยันสิ่งต่าง ๆ เกี่ยวกับข้อยกเว้นแต่ละอย่างในวิธี [ทดสอบ] ของตัวเอง จากนั้นคุณสามารถยืนยันสิ่งอื่น ๆ เกี่ยวกับวัตถุที่อยู่ภายใต้การทดสอบเพื่อให้แน่ใจว่าไม่มีผลข้างเคียงที่ไม่ได้ตั้งใจจากการโยนยกเว้น

ตัวอย่าง (สิ่งนี้จะถูกแบ่งเป็นหลายไฟล์):

namespace Tests.AcctTests
{
    [TestFixture]
    public class no_events
    {
        private Acct _acct;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
        }

        [Test]
        public void balance_0() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }

    [TestFixture]
    public class try_withdraw_0
    {
        private Acct _acct;
        private List<string> _problems;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
            Assert.That(_acct.Balance, Is.EqualTo(0));
            _problems = _acct.Withdraw(0m);
        }

        [Test]
        public void has_problem() {
            Assert.That(_problems, Is.EquivalentTo(new string[] { "Withdraw amount must be greater than zero." }));
        }

        [Test]
        public void balance_not_changed() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }

    [TestFixture]
    public class try_withdraw_negative
    {
        private Acct _acct;
        private List<string> _problems;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
            Assert.That(_acct.Balance, Is.EqualTo(0));
            _problems = _acct.Withdraw(-0.01m);
        }

        [Test]
        public void has_problem() {
            Assert.That(_problems, Is.EquivalentTo(new string[] { "Withdraw amount must be greater than zero." }));
        }

        [Test]
        public void balance_not_changed() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }
}

การยืนยันหลายครั้งในการทดสอบเดียวกันนั้นเป็นปัญหาเมื่อการทดสอบล้มเหลว จากนั้นคุณอาจต้องทำการดีบักการทดสอบหรือวิเคราะห์ข้อยกเว้นเพื่อค้นหาว่าการยืนยันนั้นเป็นแบบใด ด้วยการยืนยันเพียงครั้งเดียวในการทดสอบแต่ละครั้งมักจะง่ายต่อการระบุสิ่งที่ผิด

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

หากการทดสอบของคุณล้มเหลวคุณจะไม่ทราบว่าการยืนยันดังต่อไปนี้จะเกิดขึ้นเช่นกัน บ่อยครั้งที่หมายความว่าคุณจะพลาดข้อมูลที่มีค่าเพื่อค้นหาสาเหตุของปัญหา โซลูชันของฉันคือใช้หนึ่งยืนยัน แต่มีหลายค่า:

String actual = "val1="+val1+"\nval2="+val2;
assertEquals(
    "val1=5\n" +
    "val2=hello"
    , actual
);

นั่นทำให้ฉันเห็นการยืนยันที่ล้มเหลวทั้งหมดในครั้งเดียว ฉันใช้หลายบรรทัดเพราะ IDE ส่วนใหญ่จะแสดงความแตกต่างของสตริงในกล่องโต้ตอบการเปรียบเทียบแบบเคียงข้างกัน

หากคุณมีการยืนยันหลายครั้งในฟังก์ชั่นการทดสอบเดียวฉันคาดว่าพวกเขาจะเกี่ยวข้องโดยตรงกับการทดสอบที่คุณกำลังทำอยู่ ตัวอย่างเช่น,

@Test
test_Is_Date_segments_correct {

   // It is okay if you have multiple asserts checking dd, mm, yyyy, hh, mm, ss, etc. 
   // But you would not have any assert statement checking if it is string or number,
   // that is a different test and may be with multiple or single assert statement.
}

มีการทดสอบจำนวนมาก (แม้ว่าคุณจะรู้สึกว่ามันอาจจะเป็น overkill) ก็ไม่ใช่เรื่องเลวร้าย คุณสามารถยืนยันว่าการทดสอบที่สำคัญและสำคัญที่สุดนั้นสำคัญกว่า ดังนั้นเมื่อคุณอ้างสิทธิ์ตรวจสอบให้แน่ใจว่าข้อความยืนยันของคุณอยู่ในตำแหน่งที่ถูกต้องแทนที่จะต้องกังวลเกี่ยวกับการยืนยันหลายครั้งมากเกินไป หากคุณต้องการมากกว่าหนึ่งให้ใช้มากกว่าหนึ่ง

เป้าหมายของการทดสอบหน่วยคือการให้ข้อมูลมากที่สุดเท่าที่จะเป็นไปได้เกี่ยวกับสิ่งที่ล้มเหลว แต่ยังช่วยระบุปัญหาพื้นฐานที่สำคัญที่สุดได้อย่างแม่นยำก่อน เมื่อคุณทราบอย่างเป็นเหตุเป็นผลว่าการยืนยันหนึ่งครั้งจะล้มเหลวเนื่องจากการยืนยันอีกครั้งล้มเหลวหรือกล่าวอีกนัยหนึ่งว่ามีความสัมพันธ์แบบพึ่งพาระหว่างการทดสอบดังนั้นจึงเหมาะสมที่จะม้วนสิ่งเหล่านี้เป็นแบบทดสอบหลายชุดในการทดสอบเดี่ยว สิ่งนี้มีประโยชน์ในการไม่ทิ้งขยะผลการทดสอบด้วยความล้มเหลวที่เห็นได้ชัดซึ่งอาจถูกกำจัดได้หากเราประกันตัวในการยืนยันครั้งแรกภายในการทดสอบครั้งเดียว ในกรณีที่ไม่มีความสัมพันธ์นี้การกำหนดลักษณะตามธรรมชาติก็จะแยกการยืนยันเหล่านี้ออกเป็นแบบทดสอบเดี่ยวเพราะมิฉะนั้นการค้นหาความล้มเหลวเหล่านี้จะต้องมีการทดสอบซ้ำหลายรอบเพื่อให้สามารถแก้ปัญหาทั้งหมดได้

หากคุณออกแบบหน่วย / คลาสในลักษณะที่ต้องมีการทดสอบที่ซับซ้อนมากเกินไปจะต้องมีการเขียนมันทำให้ภาระน้อยลงในระหว่างการทดสอบและอาจส่งเสริมการออกแบบที่ดีขึ้น

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

การทดสอบหน่วยที่เหมาะสมควรล้มเหลวด้วยเหตุผลเดียวนั่นคือเหตุผลที่คุณควรใช้หนึ่งยืนยันต่อการทดสอบหน่วย

ฉันไม่เคยพบสูตรเช่นนั้นจะเป็นประโยชน์ (ที่ชั้นควรมีเหตุผลหนึ่งที่จะเปลี่ยนเป็นตัวอย่างของสุภาษิตที่ไม่ช่วยเหลือเช่นนั้น) พิจารณาการยืนยันว่าสองสายมีค่าเท่ากันนี่คือความหมายเชิงเทียบเท่ากับการยืนยันว่าความยาวของสองสายเหมือนกันและแต่ละอักขระที่ดัชนีที่สอดคล้องกันมีค่าเท่ากัน

เราสามารถพูดคุยและพูดว่าระบบใด ๆ ของการยืนยันหลาย ๆ สามารถเขียนใหม่เป็นการยืนยันเดียวและการยืนยันเดียวใด ๆ ที่สามารถย่อยสลายเป็นชุดของการยืนยันที่มีขนาดเล็ก

ดังนั้นเพียงแค่มุ่งเน้นไปที่ความชัดเจนของรหัสและความชัดเจนของผลการทดสอบและให้คำแนะนำนั้นเป็นจำนวนของการยืนยันที่คุณใช้มากกว่าที่จะกลับกัน

คำตอบนั้นง่ายมาก - ถ้าคุณทดสอบฟังก์ชั่นที่เปลี่ยนแปลงมากกว่าหนึ่งคุณสมบัติของวัตถุเดียวกันหรือแม้แต่สองวัตถุที่แตกต่างกันและความถูกต้องของฟังก์ชั่นนั้นขึ้นอยู่กับผลลัพธ์ของการเปลี่ยนแปลงเหล่านั้นทั้งหมดแล้วคุณต้องการยืนยัน ว่าการเปลี่ยนแปลงเหล่านั้นถูกดำเนินการอย่างถูกต้อง!

ฉันได้ความคิดเกี่ยวกับแนวคิดเชิงตรรกะ แต่ข้อสรุปกลับกันจะบอกว่าไม่มีฟังก์ชั่นใดที่จะต้องเปลี่ยนวัตถุมากกว่าหนึ่งวัตถุ แต่นั่นเป็นไปไม่ได้ที่จะนำไปใช้ในทุกกรณีในประสบการณ์ของฉัน

ใช้แนวคิดเชิงตรรกะของการทำธุรกรรมธนาคาร - การถอนเงินจากบัญชีธนาคารหนึ่งในกรณีส่วนใหญ่จะรวมถึงการเพิ่มจำนวนเงินนั้นไปยังบัญชีอื่น คุณไม่ต้องการแยกสองสิ่งพวกเขาสร้างหน่วยอะตอม คุณอาจต้องการทำฟังก์ชั่นสองอย่าง (ถอน / เพิ่มเงิน) และเขียนการทดสอบสองหน่วยที่แตกต่างกัน - เพิ่มเติม แต่การกระทำทั้งสองนั้นจะต้องเกิดขึ้นภายในหนึ่งธุรกรรมและคุณต้องการแน่ใจว่าธุรกรรมนั้นใช้งานได้ ในกรณีนั้นมันไม่เพียงพอที่จะทำให้แน่ใจว่าแต่ละขั้นตอนสำเร็จ คุณต้องตรวจสอบทั้งบัญชีธนาคารในการทดสอบของคุณ

อาจมีตัวอย่างที่ซับซ้อนกว่าซึ่งคุณจะไม่ทดสอบในการทดสอบหน่วยในตอนแรก แต่เป็นการทดสอบการรวมหรือการยอมรับแทน แต่ขอบเขตเหล่านั้นคล่องแคล่ว IMHO! การตัดสินใจไม่ใช่เรื่องง่ายมันเป็นเรื่องของสถานการณ์และความชอบส่วนตัว การถอนเงินจากบัญชีหนึ่งและเพิ่มไปยังบัญชีอื่นยังคงเป็นฟังก์ชั่นที่ง่ายมากและเป็นผู้สมัครสำหรับการทดสอบหน่วย

คำถามนี้เกี่ยวข้องกับปัญหาคลาสสิกของการปรับสมดุลระหว่างปัญหาเกี่ยวกับสปาเก็ตตี้และลาซานญ่า

การมีหลาย asserts สามารถทำให้เกิดปัญหาปาเก็ตตี้ได้ง่าย ๆ โดยที่คุณไม่รู้ว่าการทดสอบนั้นเกี่ยวกับอะไร แต่การมี assert เพียงครั้งเดียวต่อการทดสอบนั้นจะทำให้การทดสอบของคุณไม่สามารถอ่านได้อย่างเท่าเทียมกัน .

มีข้อยกเว้นบางประการ แต่ในกรณีนี้การรักษาลูกตุ้มที่อยู่ตรงกลางคือคำตอบ

ฉันไม่เห็นด้วยกับ "ล้มเหลวด้วยเหตุผลเดียวเท่านั้น" โดยทั่วไป สิ่งที่สำคัญกว่าคือการทดสอบนั้นสั้นและอ่านได้ชัดเจน

สิ่งนี้ไม่สามารถทำได้ตลอดเวลาและเมื่อการทดสอบมีความซับซ้อนชื่อที่สื่อความหมาย (ยาว) และการทดสอบสิ่งต่าง ๆ มีน้อยลง