คุณเขียนรหัส“ ของจริง” ใน TDD เมื่อใด

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

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

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

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

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

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

ในการดำเนินการโรงเรียนยากที่จะมองเห็น บัญชีแยกประเภทตัวเลขและธนาคารเป็น "ง่าย" ในแง่ที่คุณสามารถใช้เลขคณิตอย่างง่าย ฉันสามารถเห็นเครื่องหมาย + b และส่งกลับ 0 เป็นต้นในกรณีของระบบคนฉันต้องคิดให้มากขึ้นว่าจะใช้งานอย่างไร ฉันมีแนวคิดเกี่ยวกับความล้มเหลว, การผ่าน, refactor (ส่วนใหญ่เป็นเพราะการศึกษาและคำถามนี้)

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

หรือบางทีนี่อาจแสดงว่าฉันยังสับสนอยู่

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

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

ส่วนไหนที่คุณเขียนโค้ดก่อนที่จะทำการทดสอบอีกครั้ง ไม่มี. คุณเขียนรหัสศูนย์โดยไม่มีการทดสอบที่ล้มเหลวที่บังคับให้คุณเขียนรหัสเพิ่มเติม

สังเกตรูปแบบหรือไม่

ลองทำตัวอย่างง่ายๆ (อีก) ด้วยความหวังว่ามันจะช่วยได้

Assert.Equal("1", FizzBuzz(1));

ง่าย peazy

public String FizzBuzz(int n) {
    return 1.ToString();
}

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

Assert.Equal("2", FizzBuzz(2));

เราสามารถทำอะไรที่โง่ได้if n == 1แต่เราจะข้ามไปที่วิธีแก้ปัญหาที่มีสติ

public String FizzBuzz(int n) {
    return n.ToString();
}

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

Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
}

และอีกครั้ง. เขียนการทดสอบที่ยังไม่ผ่าน

Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
}

และตอนนี้เราได้ครอบคลุมทวีคูณของสามทั้งหมด (นั่นไม่ใช่ทวีคูณของห้าเราจะทราบและกลับมา)

เรายังไม่ได้เขียนการทดสอบสำหรับ "Buzz" ดังนั้นลองเขียนว่า

Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
}

และอีกครั้งเรารู้ว่ามีอีกกรณีที่เราต้องจัดการ

Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
}

และตอนนี้เราสามารถจัดการทวีคูณของ 5 ทั้งหมดที่ไม่ใช่ทวีคูณของ 3

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

private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
}

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

Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
}

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

public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
}

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

public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
}

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

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

• เชิงลบ
• ศูนย์
• หนึ่ง
• สอง
• สาม
• สี่
• ห้า
• หก (ไม่ใช่ผลคูณเล็กน้อยของ 3)
• เก้า (3 กำลังสอง)
• สิบ (ไม่ใช่ผลคูณเล็กน้อยของ 5)
• 15 (หลาย 3 & 5)
• 30 (ไม่ใช่ผลคูณเล็กน้อยของ 3 และ 5)

รหัส "ของจริง" คือรหัสที่คุณเขียนเพื่อให้ผ่านการทดสอบของคุณ จริงๆ มันง่ายมาก

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

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

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

คำตอบสั้น ๆ คือ "รหัสจริง" เป็นรหัสที่ทำให้ผ่านการทดสอบ หากคุณสามารถทำแบบทดสอบผ่านสิ่งอื่นนอกเหนือจากรหัสจริงให้เพิ่มการทดสอบมากขึ้น!

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

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

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

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

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

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

บ๊อบมาร์ตินอธิบายได้ดีที่สุดที่นี่

ส่วน refactor นั้นสะอาดเมื่อคุณเหนื่อยและอยากกลับบ้าน

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

สิ่งนี้สามารถทำได้ง่ายเพียงแค่เปลี่ยนชื่อGreetImplเป็นGreetWorldก่อนที่คุณจะสร้างGreetMomคลาส (หลังจากเพิ่มการทดสอบ) เพื่อเพิ่มคุณสมบัติที่จะพิมพ์ "Hi Mom"

แต่รหัสจริงจะปรากฏในระยะ refactor ของเฟส TDD เช่นรหัสที่ควรเป็นส่วนหนึ่งของรุ่นสุดท้าย

ควรทำการทดสอบทุกครั้งที่มีการเปลี่ยนแปลง

คำขวัญของวัฏจักรชีวิตของ TDD คือ: RED GREEN REFACTOR

RED : เขียนแบบทดสอบ

GREEN : พยายามอย่างเต็มที่เพื่อให้ได้รหัสการทำงานที่ผ่านการทดสอบโดยเร็วที่สุด: รหัสที่ซ้ำกันตัวแปรที่มีชื่อไม่ชัดเจนแฮ็กของลำดับสูงสุดเป็นต้น

REFACTOR : ทำความสะอาดโค้ดตั้งชื่อตัวแปรให้ถูกต้อง ลองรหัส

คุณเขียนรหัส“ ของจริง” ใน TDD เมื่อใด

แดงเฟสคือที่ที่คุณเขียนรหัส

ในrefactoringเฟสเป้าหมายหลักคือการลบรหัส

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

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

ในที่สุดคุณก็ปรับปรุงความสามารถในการอ่านโดยการเปลี่ยนชื่อตัวระบุและแยกหมายเลขเวทย์มนตร์และ / หรือสตริงตัวอักษรให้อยู่

มันไม่ใช่ refactor สีแดง แต่เป็น red-green-refactor - Rob Kinyon

ขอบคุณที่ชี้ไปที่สิ่งนี้

ดังนั้นจึงเป็นเฟสสีเขียวที่คุณเขียนโค้ดจริง

ในเฟสสีแดงคุณเขียนข้อมูลจำเพาะที่สามารถเรียกทำงานได้ ...

คุณกำลังเขียนรหัสจริงตลอดเวลา

ในแต่ละขั้นตอนคุณกำลังเขียนรหัสเพื่อตอบสนองเงื่อนไขที่รหัสของคุณจะพึงพอใจสำหรับผู้โทรในอนาคตของรหัสของคุณ (ซึ่งอาจเป็นคุณหรือไม่ ... )

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

การเปลี่ยนรหัสใหม่ เป็นกระบวนการของการปรับโครงสร้างรหัสคอมพิวเตอร์ที่มีอยู่เดิม - เปลี่ยนแฟคตอริ่งโดยไม่เปลี่ยนพฤติกรรมภายนอก

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

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

เมื่อฉันอ่าน The Book (*) บน TDD สำหรับฉันคุณสมบัติที่สำคัญที่สุดที่โดดเด่นคือ: รายการสิ่งที่ต้องทำ มันแสดงให้เห็นว่า TDD เป็นเทคนิคที่ช่วยให้นักพัฒนามุ่งเน้นไปที่สิ่งหนึ่งในเวลา ดังนั้นเรื่องนี้ก็เป็นคำตอบให้กับคำถามของคุณ aboout วิธีรหัสจริงมากที่จะเขียน ? ฉันจะบอกว่ารหัสเพียงพอที่จะมุ่งเน้นไปที่สิ่งที่ 1 ในเวลา

(*) "การพัฒนาแบบทดสอบที่ขับเคลื่อนด้วยตัวอย่าง" โดย Kent Beck

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

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

จุดทั้งหมดเกี่ยวกับการเขียนการทดสอบเริ่มต้นที่ล้มเหลวคือการทำสองสิ่ง:

1. ครอบคลุมทุกกรณี - ทุกกรณีเล็กน้อยทุกกรณีขอบ ฯลฯ
2. ตรวจสอบการทดสอบของคุณ หากคุณเคยเห็นพวกเขาผ่านไปคุณจะมั่นใจได้อย่างไรว่าพวกเขาจะรายงานความล้มเหลวได้อย่างน่าเชื่อถือเมื่อเกิดขึ้น

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

ในประสบการณ์ของฉัน (C # /. NET) การทดสอบครั้งแรกนั้นเป็นวิธีที่ไม่สามารถบรรลุได้เพราะคุณไม่สามารถรวบรวมการเรียกไปยังวิธีที่ยังไม่มีอยู่ ดังนั้น "การทดสอบครั้งแรก" นั้นเกี่ยวกับการเขียนโค้ดอินเทอร์เฟซและการใช้งานการขัดครั้งแรกจากนั้นจึงเขียนการทดสอบกับสตับ (ซึ่งจะล้มเหลวในขั้นต้น) จนกว่าสแต็กจะถูกทำให้อ้วน ฉันไม่เคยเขียน "รหัสที่ล้มเหลว" เพียงแค่สร้างจากสตับ

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

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

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

ทั้งหมดนี้คือการทดสอบ ALSO แต่ฉันไม่มีหน้าจอสีแดง / เขียวสวยสำหรับผลลัพธ์ อาจสำเร็จหรือฉันขุดผ่านรหัสข้อผิดพลาดสองสามพันบรรทัดเพื่อค้นหาสาเหตุ

นั่นคือสิ่งที่คุณทดสอบ "รหัสจริง"

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

ในการตอบชื่อเรื่องของคำถาม: "คุณเขียนรหัส" ของจริง "ใน TDD เมื่อไหร่?" คำตอบคือ: 'แทบจะไม่เคย' หรือ 'ช้ามาก'

คุณฟังดูเหมือนนักเรียนดังนั้นฉันจะตอบเหมือนให้คำแนะนำนักเรียน

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

งานของ coder นั้นใช้เพื่อสร้างรหัสเท่านั้น รหัสที่ใช้งานได้ดีจริงๆ นั่นคือเหตุผลที่คุณ coder วางแผนโค้ดในใจของคุณบนกระดาษในแอพพลิเคชั่นที่เหมาะสม ฯลฯ และคุณวางแผนที่จะแก้ไขข้อบกพร่อง / หลุมที่อาจเกิดขึ้นล่วงหน้าโดยการคิดอย่างมีเหตุผลและในภายหลังก่อนการเข้ารหัส

แต่คุณต้องรู้วิธีแบ่งแอปพลิเคชันของคุณเพื่อให้สามารถออกแบบรหัสที่เหมาะสมได้ ตัวอย่างเช่นหากคุณไม่ทราบเกี่ยวกับLittle Bobby Table (xkcd 327) คุณอาจจะไม่ฆ่าเชื้ออินพุตของคุณก่อนทำงานกับฐานข้อมูลดังนั้นคุณจะไม่สามารถรักษาความปลอดภัยข้อมูลของคุณตามแนวคิดนั้น

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

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

โปรดอย่าวางกับดักนี้และดูบทบาทของคุณในการเข้ารหัสว่ามันคืออะไร - งานของ coder นั้นใช้เพื่อสร้างรหัสเท่านั้น รหัสที่ใช้งานได้ดีจริงๆ ตอนนี้จำไว้ว่าคุณจะอยู่ในฐานะ coder มืออาชีพและลูกค้าของคุณจะไม่สนใจว่าคุณเขียน 100,000 คำยืนยันหรือ 0 พวกเขาต้องการโค้ดที่ใช้งานได้ จริงๆแล้วในความเป็นจริง