TDD และการครอบคลุมการทดสอบที่สมบูรณ์ในกรณีที่จำเป็นต้องมีการทดสอบแบบเลขชี้กำลัง

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

1. ตรงกับชื่อ
2. คำค้นหาทั้งหมดในชื่อหรือคำพ้องความหมายของผลลัพธ์
3. คำค้นหาบางคำในชื่อหรือคำพ้องความหมายของผลลัพธ์ (% จากมากไปหาน้อย)
4. คำทั้งหมดของคำค้นหาในคำอธิบาย
5. คำบางส่วนของคำค้นหาในคำอธิบาย (% มากไปหาน้อย)
6. วันที่แก้ไขล่าสุดจากมากไปน้อย

ตัวเลือกการออกแบบตามธรรมชาติสำหรับตัวเปรียบเทียบนี้ดูเหมือนจะเป็นอันดับที่จัดอันดับขึ้นอยู่กับพลังของ 2 ผลรวมของกฎที่สำคัญน้อยกว่านั้นไม่สามารถเป็นได้มากกว่าการจับคู่เชิงบวกกับกฎที่มีความสำคัญสูงกว่า นี่คือความสำเร็จโดยคะแนนต่อไปนี้:

1. 32
2. 16
3. 8 (คะแนน tie-breaker รองตาม% จากมากไปน้อย)
4. 4
5. 2 (คะแนน tie-breaker รองตาม% จากมากไปน้อย)
6. 1

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

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

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

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

จากนั้นเริ่มต้นด้วยข้อกำหนดที่ 2:

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

ที่นี่มาจับ : เมื่อคุณเพิ่มกรณีทดสอบสำหรับความต้องการ / หมายเลขหมวดหมู่ "n" คุณจะต้องเพิ่มการทดสอบเพื่อให้แน่ใจว่าคะแนนของหมวดหมู่ "n-1" สูงกว่าคะแนนสำหรับหมวดหมู่ "n" . คุณจะไม่ต้องเพิ่มกรณีทดสอบใด ๆ สำหรับชุดค่าผสมประเภทที่ 1, ... , n-1 อื่น ๆ เนื่องจากการทดสอบที่คุณเขียนไว้ก่อนหน้านี้จะทำให้แน่ใจว่าคะแนนของหมวดหมู่นั้นจะยังคงอยู่ในลำดับที่ถูกต้อง

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

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

สิ่งนี้สามารถทดสอบได้ง่ายมากโดยใช้การทดสอบที่ล้อเลียนเพียงไม่กี่ข้อ

จากนั้นคุณสามารถเขียนคลาสสำหรับแต่ละเงื่อนไขและมีเพียง 2 การทดสอบสำหรับแต่ละกรณี

ฉันไม่เข้าใจกรณีการใช้งานของคุณจริงๆ แต่หวังว่าตัวอย่างนี้จะช่วยได้

public class ScoreBuilder
{
    private ISingleScorableCondition[] _conditions;
    public ScoreBuilder (ISingleScorableCondition[] conditions)
    {
        _conditions = conditions;
    }

    public int GetScore(string toBeScored)
    {
        foreach (var condition in _conditions)
        {
            if (_conditions.Test(toBeScored))
            {
                // score this somehow
            }
        }
    }
}

public class ExactMatchOnNameCondition : ISingleScorableCondition
{
    private IDataSource _dataSource;
    public ExactMatchOnNameCondition(IDataSource dataSource)
    {
        _dataSource = dataSource;
    }

    public bool Test(string toBeTested)
    {
        return _dataSource.Contains(toBeTested);
    }
}

// etc

คุณจะสังเกตเห็นว่าการทดสอบเงื่อนไข 2 ^ ของคุณจะลดลงอย่างรวดเร็วถึง 4+ (2 * เงื่อนไข) 20 ยิ่งน้อยกว่า 64 มากและถ้าคุณเพิ่มอีกหนึ่งครั้งในภายหลังคุณไม่จำเป็นต้องเปลี่ยนคลาสที่มีอยู่ใด ๆ (หลักการแบบเปิดปิด) ดังนั้นคุณไม่จำเป็นต้องเขียนแบบทดสอบใหม่ 64 แบบคุณเพียงแค่มี เพื่อเพิ่มคลาสอีกคลาสด้วยการทดสอบใหม่ 2 รายการและเพิ่มเข้าไปในคลาส ScoreBuilder ของคุณ

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

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

การทดสอบครั้งที่สองจะคุ้มค่าเพราะครอบคลุมเส้นทางที่แตกต่างผ่านรหัสอาจตรวจสอบความสัมพันธ์ลำดับความสำคัญอื่น

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

นี่เป็นระดับของการทดสอบที่มักจะถูกเรียกเมื่อพูดถึงการครอบคลุมการทดสอบ 100% ใน TDD หรือไม่?

ความเข้าใจของฉันคือความครอบคลุม 100% หมายความว่าการใช้รหัสเส้นทางทั้งหมด นี่ไม่ได้หมายความว่าคุณทำชุดค่าผสมทั้งหมดของกฎของคุณ แต่เส้นทางที่แตกต่างกันทั้งหมดที่รหัสของคุณอาจลงไปได้ แต่เนื่องจากคุณกำลังทำ TDD ยังไม่มี "รหัส" ที่ยังตรวจสอบเส้นทาง ตัวอักษรของกระบวนการจะบอกว่าทำให้ทั้งหมด 63+

โดยส่วนตัวฉันพบว่าการปกปิด 100% นั้นเป็นความฝันที่ไพเราะ ยิ่งไปกว่านั้นมันไม่สามารถคาดการณ์ได้ มีการทดสอบหน่วยเพื่อให้บริการคุณไม่ใช่ในทางกลับกัน เมื่อคุณทำการทดสอบเพิ่มเติมคุณจะได้รับผลตอบแทนที่ลดลงจากผลประโยชน์ (โอกาสที่การทดสอบจะป้องกันข้อผิดพลาด + ความมั่นใจว่ารหัสนั้นถูกต้อง) ขึ้นอยู่กับว่ารหัสของคุณกำหนดตำแหน่งของสไลเดอร์ที่คุณหยุดทำการทดสอบ หากรหัสของคุณใช้เครื่องปฏิกรณ์นิวเคลียร์การทดสอบ 63+ ครั้งอาจจะคุ้มค่า หากรหัสของคุณจัดระเบียบไฟล์เก็บถาวรเพลงของคุณคุณอาจไม่ต้องไปไหนมากนัก

ฉันขอยืนยันว่านี่เป็นกรณีที่สมบูรณ์แบบสำหรับ TDD

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

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

ฉันไม่ได้เป็นแฟนของการตีความการทดสอบที่ครอบคลุม 100% อย่างเคร่งครัดเนื่องจากการเขียนรายละเอียดเกี่ยวกับวิธีการทุกวิธีหรือการทดสอบการเปลี่ยนรหัสทุกครั้ง การทำเช่นนี้มีแนวโน้มที่จะนำไปสู่การออกแบบที่ขับเคลื่อนด้วยการทดสอบของชั้นเรียนของคุณที่ไม่ถูกต้องในแค็ปซูลตรรกะทางธุรกิจและให้ผลการทดสอบ / รายละเอียดที่โดยทั่วไปไม่มีความหมายในแง่ของการอธิบายตรรกะทางธุรกิจ แต่ฉันมุ่งเน้นไปที่การสร้างโครงสร้างการทดสอบคล้ายกับกฎเกณฑ์ทางธุรกิจของตัวเองและมุ่งมั่นที่จะออกกำลังกายทุกส่วนตามเงื่อนไขของรหัสด้วยการทดสอบด้วยความคาดหวังที่ชัดเจนว่าการทดสอบนั้นเป็นที่เข้าใจง่ายโดยผู้ทดสอบ กฎเกณฑ์ทางธุรกิจที่นำมาใช้

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

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

ในกรณีที่ # 2 / # 3 และ # 4 / # 5 เป็นวิธีการทั่วไปที่เหมือนกัน แต่ผ่านเขตข้อมูลที่แตกต่างกันในคุณจะต้องเขียนหนึ่งชุดของการทดสอบหน่วยสำหรับวิธีการพื้นฐานและเขียนการทดสอบหน่วยเพิ่มเติมง่าย ๆ เพื่อทดสอบเฉพาะ ฟิลด์ (ชื่อ, ชื่อ, คำอธิบาย, ฯลฯ ) และการให้คะแนนตามแฟคตอริ่งที่กำหนดดังนั้นสิ่งนี้จะช่วยลดความซ้ำซ้อนของความพยายามในการทดสอบโดยรวมของคุณ

ด้วยวิธีนี้วิธีการที่อธิบายไว้ข้างต้นอาจให้ผลการทดสอบ 3 หรือ 4 ครั้งในกรณีที่ # 1 บางที 10 specs ในบางส่วน / ทั้งหมด / คำพ้องความหมาย - บวก 4 specs ในการให้คะแนนที่ถูกต้องของ # 2 - # 5 และ 2 ข้อมูลจำเพาะ 3 ข้อในวันสุดท้ายที่ได้รับคำสั่งการจัดอันดับจากนั้นการทดสอบระดับการรวม 3 ถึง 4 แบบซึ่งวัดทั้ง 6 กรณีที่รวมกันในรูปแบบที่เป็นไปได้ (ลืมกรณีขอบที่คลุมเครือในตอนนี้ยกเว้นกรณีที่คุณเห็นปัญหาในรหัสของคุณอย่างชัดเจน เงื่อนไขนั้นได้รับการจัดการ) หรือทำให้แน่ใจว่าจะไม่ได้รับการละเมิด / ทำลายจากการแก้ไขในภายหลัง นั่นให้รายละเอียดประมาณ 25 หรือมากกว่านั้นเพื่อออกกำลังกาย 100% ของโค้ดที่เขียน (แม้ว่าคุณจะไม่ได้เรียก 100% ของวิธีการที่เขียนโดยตรง)

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

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

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

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