TDD และการทดสอบหน่วยคืออะไร [การแปล]

บทความนี้เป็นการดัดแปลงจากหนังสือ The Complete Software Career Guide ผู้เขียน จอห์น ซอนเมซ เขียนและโพสต์บางบทบนเว็บไซต์ของเขา

อภิธานศัพท์สั้นๆ สำหรับผู้เริ่มต้น

การทดสอบหน่วยหรือการทดสอบหน่วยเป็นกระบวนการในการเขียนโปรแกรมที่ช่วยให้คุณสามารถตรวจสอบแต่ละโมดูลของซอร์สโค้ดของโปรแกรมว่ามีความถูกต้องหรือไม่ แนวคิดก็คือการเขียนการทดสอบสำหรับฟังก์ชันหรือเมธอดเล็กๆ น้อยๆ ทั้งหมด การทดสอบการถดถอยเป็นชื่อทั่วไปสำหรับการทดสอบซอฟต์แวร์ทุกประเภทที่มุ่งตรวจจับข้อผิดพลาดในพื้นที่ที่ทดสอบแล้วของซอร์สโค้ด ข้อผิดพลาดดังกล่าว - เมื่อหลังจากทำการเปลี่ยนแปลงโปรแกรมแล้ว สิ่งที่ควรทำงานต่อไปหยุดทำงาน - เรียกว่าข้อผิดพลาดการถดถอย ผลสีแดง ล้มเหลว - ล้มเหลวในการทดสอบ ความแตกต่างระหว่างผลลัพธ์ที่คาดหวังกับผลลัพธ์จริง ผลสีเขียว ผ่าน - ผลการทดสอบเป็นบวก ผลลัพธ์ที่แท้จริงก็ไม่ต่างจากสิ่งที่ได้รับ *** ฉันมีความสัมพันธ์ที่หลากหลายมากกับ Test Driven Development (TDD) และการทดสอบหน่วย โดยเปลี่ยนจากความรักไปสู่ความเกลียดชังและกลับมาอีกครั้ง ฉันเป็นแฟนตัวยงและในขณะเดียวกันก็เป็นคนขี้สงสัยเกี่ยวกับการใช้สิ่งนี้และ "แนวทางปฏิบัติที่ดีที่สุด" อื่นๆ เหตุผลสำหรับทัศนคติของฉันนั้นมาจากความจริงที่ว่าปัญหาร้ายแรงเกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์: นักพัฒนาและบางครั้งผู้จัดการใช้เครื่องมือและวิธีการบางอย่างเพียงเพราะว่าสิ่งเหล่านี้อยู่ใน "แนวปฏิบัติที่ดีที่สุด" เหตุผลที่แท้จริงในการใช้งานยังไม่ชัดเจน วันหนึ่งฉันเริ่มทำงานในโครงการหนึ่ง และในกระบวนการนี้ ฉันได้รับแจ้งว่าเราจะแก้ไขโค้ดที่ครอบคลุมโดยการทดสอบหน่วยจำนวนมาก ไม่ใช่เรื่องตลก มีประมาณ 3,000 ตัว นี่เป็นสัญญาณที่ดีซึ่งเป็นสัญญาณว่านักพัฒนาซอฟต์แวร์กำลังใช้วิธีการขั้นสูง โค้ดด้วยวิธีนี้มักมีโครงสร้างและมีพื้นฐานมาจากสถาปัตยกรรมที่คิดมาอย่างดี กล่าวอีกนัยหนึ่ง การมีการทดสอบทำให้ฉันมีความสุข หากเพียงเพราะมันทำให้งานของฉันในฐานะที่ปรึกษาของโปรแกรมเมอร์ง่ายขึ้น เนื่องจากเรามีการทดสอบหน่วยแล้ว สิ่งที่ฉันต้องทำคือเชื่อมต่อทีมพัฒนาเพื่อสนับสนุนพวกเขา และเริ่มเขียนโค้ดของเราเอง ฉันเปิด IDE (สภาพแวดล้อมการพัฒนาแบบรวม) และโหลดโปรเจ็กต์ มันเป็นโครงการใหญ่! ฉันพบโฟลเดอร์ชื่อ "การทดสอบหน่วย" “เยี่ยมมาก” ฉันคิดว่า - มาเปิดตัวและดูว่าเกิดอะไรขึ้น ใช้เวลาเพียงไม่กี่นาที และฉันก็ประหลาดใจที่การทดสอบทั้งหมดผ่านไป ทุกอย่างเป็นสีเขียว ( "สีเขียว" เป็นผลบวกของการทดสอบ สัญญาณว่าโค้ดทำงานตามที่คาดไว้ สีแดงหมายถึง "ล้มเหลว" หรือล้มเหลว จากนั้น มีกรณีที่รหัสทำงานไม่ถูกต้อง - หมายเหตุผู้แปล ) พวกเขาทั้งหมดผ่านการทดสอบ ในขณะนั้นผู้ขี้ระแวงในตัวฉันตื่นขึ้นมา ทำไมการทดสอบสามพันหน่วยและพวกเขาทำทั้งหมดพร้อมกัน - และให้ผลลัพธ์ที่เป็นบวก? ในการฝึกฝนอันยาวนานของฉัน ฉันจำไม่ได้ว่าเมื่อใดที่ฉันเริ่มทำงานในโครงการโดยไม่มีการทดสอบหน่วยลบในโค้ดเลย จะทำอย่างไร? ตรวจสอบด้วยตนเอง! ChY เลือกการทดสอบแบบสุ่มหนึ่งรายการ ไม่ใช่การทดสอบที่เปิดเผยที่สุด แต่ก็ชัดเจนทันทีว่าเขากำลังตรวจสอบอะไร แต่ในขณะที่ดำเนินการอยู่ ฉันสังเกตเห็นบางสิ่งที่ไร้สาระ: การทดสอบไม่มีการเปรียบเทียบกับผลลัพธ์ที่คาดหวัง (ยืนยัน)! นั่นคือ ในความเป็นจริงไม่มีอะไรถูกตรวจสอบเลย ! มีขั้นตอนบางอย่างในการทดสอบ แต่ก็มีการดำเนินการ แต่เมื่อสิ้นสุดการทดสอบซึ่งเขาควรเปรียบเทียบผลลัพธ์จริงและที่คาดหวังไว้ กลับไม่มีการตรวจสอบ "การทดสอบ" ไม่ได้ทดสอบอะไรเลย ฉันเปิดการทดสอบอีกครั้ง ยิ่งไปกว่านั้น: ตัวดำเนินการเปรียบเทียบกับผลลัพธ์ได้รับการใส่ความคิดเห็นแล้ว เก่งมาก! นี่เป็นวิธีที่ดีเยี่ยมในการทำการทดสอบ เพียงแสดงความคิดเห็นโค้ดที่ทำให้ล้มเหลว ฉันตรวจสอบการทดสอบอื่น แล้วก็อีก... ไม่มีใครตรวจสอบอะไรเลย การทดสอบสามพันครั้ง และการทดสอบทั้งหมดนั้นไร้ประโยชน์โดยสิ้นเชิง มีความแตกต่างอย่างมากระหว่างการเขียน Unit Test และการทำความเข้าใจ Unit Testing และ Test-Driven Development (TDD)

การทดสอบหน่วยคืออะไร?

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

บางครั้งเรียกว่าการทดสอบหน่วยอะไร

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

คุณค่าของการทดสอบหน่วย

เหตุใดฉันจึงเป็นผู้ชื่นชอบการทดสอบหน่วย เหตุใดการเรียกการทดสอบทั่วไปจึงเป็นอันตราย ซึ่งเกี่ยวข้องกับการทดสอบไม่ใช่บล็อกที่เล็กที่สุดที่แยกจากโค้ดอื่น แต่เป็นโค้ดที่ใหญ่กว่า "การทดสอบหน่วย" จะเกิดปัญหาอะไรขึ้นหากการทดสอบบางอย่างของฉันไม่เปรียบเทียบผลลัพธ์ที่ได้รับและผลลัพธ์ที่คาดหวัง อย่างน้อยพวกเขาก็รันโค้ด ฉันจะพยายามอธิบาย มีสองเหตุผลหลักในการดำเนินการทดสอบหน่วย ประการแรกคือการปรับปรุงการออกแบบโค้ด จำได้ไหมที่ฉันบอกว่าการทดสอบหน่วยไม่ใช่การทดสอบจริงๆ เมื่อคุณเขียน Unit Test ที่เหมาะสม คุณจะบังคับตัวเองให้แยกหน่วยโค้ดที่เล็กที่สุดออก ความพยายามเหล่านี้จะทำให้คุณค้นพบปัญหาในโครงสร้างของโค้ดเอง คุณอาจพบว่าเป็นเรื่องยากมากที่จะแยกคลาสทดสอบออกและไม่รวมการขึ้นต่อกันของคลาสนั้น และอาจทำให้คุณรู้ว่าโค้ดของคุณเชื่อมโยงกันแน่นเกินไป คุณอาจพบว่าฟังก์ชันหลักที่คุณพยายามทดสอบครอบคลุมหลายโมดูล ทำให้คุณเชื่อว่าโค้ดของคุณไม่สอดคล้องกันเพียงพอ เมื่อคุณนั่งลงเพื่อเขียน Unit Test คุณอาจค้นพบ (และเชื่อฉันเถอะ มันเกิดขึ้น!) ว่าคุณไม่รู้ว่า Code ควรจะทำอะไร ดังนั้นคุณจะไม่สามารถเขียนแบบทดสอบหน่วยได้ และแน่นอน คุณอาจพบจุดบกพร่องจริง ๆ ในการใช้งานโค้ด เนื่องจากการทดสอบหน่วยบังคับให้คุณคิดนอกกรอบและทดสอบชุดอินพุตต่าง ๆ ที่คุณอาจไม่ได้พิจารณา หากคุณปฏิบัติตามกฎ "ทดสอบหน่วยโค้ดที่เล็กที่สุดโดยแยกจากหน่วยอื่นๆ" อย่างเคร่งครัดเมื่อสร้างการทดสอบหน่วย คุณจะพบกับปัญหาทุกประเภทกับโค้ดนั้นและการออกแบบโมดูลเหล่านั้น ในวงจรชีวิตการพัฒนาซอฟต์แวร์ การทดสอบหน่วยเป็นกิจกรรมการประเมินมากกว่ากิจกรรมการทดสอบ เป้าหมายหลักที่สองของการทดสอบหน่วยคือการสร้างชุดการทดสอบการถดถอยอัตโนมัติที่สามารถทำหน้าที่เป็นข้อกำหนดเฉพาะของพฤติกรรมซอฟต์แวร์ในระดับต่ำ มันหมายความว่าอะไร? เมื่อคุณนวดแป้ง คุณจะไม่ทำให้แป้งแตก จากมุมมองนี้ การทดสอบหน่วยคือการทดสอบ โดยเฉพาะการทดสอบการถดถอย อย่างไรก็ตาม วัตถุประสงค์ของการทดสอบหน่วยไม่ใช่เพียงการสร้างการทดสอบการถดถอยเท่านั้น ในทางปฏิบัติ การทดสอบหน่วยแทบจะไม่สามารถตรวจจับการถดถอยได้ เนื่องจากการเปลี่ยนแปลงหน่วยของโค้ดที่คุณกำลังทดสอบมักจะมีการเปลี่ยนแปลงในการทดสอบหน่วยด้วย การทดสอบการถดถอยจะมีประสิทธิภาพมากกว่ามากในระดับที่สูงกว่า เมื่อโค้ดถูกทดสอบเป็น "กล่องดำ" เนื่องจากในระดับนี้ โครงสร้างภายในของโค้ดสามารถเปลี่ยนแปลงได้ ในขณะที่พฤติกรรมภายนอกคาดว่าจะยังคงเหมือนเดิม การทดสอบหน่วยในทางกลับกันจะตรวจสอบโครงสร้างภายใน เพื่อว่าเมื่อโครงสร้างนั้นเปลี่ยนแปลง การทดสอบหน่วยจะไม่ล้มเหลว สิ่งเหล่านี้ใช้ไม่ได้และตอนนี้จำเป็นต้องเปลี่ยน โยนทิ้ง หรือเขียนใหม่ ตอนนี้คุณรู้เพิ่มเติมเกี่ยวกับวัตถุประสงค์ที่แท้จริงของการทดสอบหน่วยมากกว่านักพัฒนาซอฟต์แวร์ที่มีประสบการณ์หลายราย

การพัฒนาแบบทดสอบขับเคลื่อน (TDD) คืออะไร?

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

เป้าหมายของ TDD คืออะไร?

Test-driven development (TDD) เช่น การทดสอบหน่วย สามารถใช้อย่างไม่ถูกต้องได้ ง่ายมากที่จะเรียกสิ่งที่คุณทำว่า "TDD" และแม้แต่ทำตามแนวทางปฏิบัติโดยไม่เข้าใจว่าทำไมคุณถึงทำแบบนั้น ค่าสูงสุดของ TDD คือการทดสอบเพื่อให้ได้ข้อกำหนดด้านคุณภาพ TDDเป็นหลักปฏิบัติในการเขียนข้อกำหนดที่แม่นยำซึ่งสามารถตรวจสอบได้โดยอัตโนมัติก่อนเขียนโค้ด การทดสอบเป็นข้อกำหนดที่ดีที่สุดเพราะไม่ได้โกหก พวกเขาจะไม่บอกคุณหลังจากผ่านไปสองสัปดาห์แห่งความทรมานด้วยรหัสว่า “นั่นไม่ใช่สิ่งที่ฉันหมายถึงเลย” การทดสอบเมื่อเขียนถูกต้องจะผ่านหรือล้มเหลว การทดสอบระบุอย่างชัดเจนถึงสิ่งที่ควรเกิดขึ้นภายใต้สถานการณ์บางอย่าง ดังนั้นเป้าหมายของ TDD คือทำให้เรามีความเข้าใจอย่างถ่องแท้ถึงสิ่งที่เราจำเป็นต้องดำเนินการก่อนที่เราจะเริ่มดำเนินการ หากคุณเริ่มต้นด้วย TDD และไม่รู้ว่าการทดสอบควรจะทดสอบอะไร คุณจำเป็นต้องถามคำถามเพิ่มเติม บทบาทที่สำคัญอีกประการหนึ่งของ TDD คือการรักษาและเพิ่มประสิทธิภาพโค้ด การบำรุงรักษาโค้ดมีราคาแพง ฉันมักจะล้อเล่นว่าโปรแกรมเมอร์ที่ดีที่สุดคือคนที่เขียนโค้ดที่สั้นที่สุดที่สามารถแก้ปัญหาบางอย่างได้ หรือแม้แต่ผู้ที่พิสูจน์ว่าปัญหานี้ไม่จำเป็นต้องได้รับการแก้ไขและด้วยเหตุนี้จึงลบโค้ดออกอย่างสมบูรณ์เนื่องจากเป็นโปรแกรมเมอร์รายนี้ที่พบวิธีที่ถูกต้องในการลดจำนวนข้อผิดพลาดและลดต้นทุนในการบำรุงรักษาแอปพลิเคชัน เมื่อใช้ TDD คุณจะมั่นใจได้อย่างแน่นอนว่าคุณไม่ได้เขียนโค้ดที่ไม่จำเป็น เนื่องจากคุณจะเขียนโค้ดเพื่อผ่านการทดสอบเท่านั้น มีหลักการพัฒนาซอฟต์แวร์ที่เรียกว่า YAGNI (คุณไม่จำเป็นต้องใช้มัน) TDD ป้องกัน YAGNI

เวิร์กโฟลว์การพัฒนาการทดสอบขับเคลื่อน (TDD) โดยทั่วไป

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

1. สร้างแบบทดสอบแล้ว
2. เราเขียนโค้ดสำหรับการทดสอบนี้
3. ปรับโครงสร้างโค้ดใหม่

ข้อสรุป

นั่นคือทั้งหมดที่ฉันต้องการจะบอกคุณเกี่ยวกับการทดสอบหน่วยและ TDD ในขั้นตอนนี้ ในความเป็นจริง มีปัญหามากมายที่เกี่ยวข้องกับการพยายามแยกโมดูลโค้ด เนื่องจากโค้ดอาจซับซ้อนและสับสนมาก มีคลาสเพียงไม่กี่คลาสเท่านั้นที่แยกออกจากกันโดยสิ้นเชิง แต่มีการขึ้นต่อกัน และการขึ้นต่อกันเหล่านั้นก็มีการขึ้นต่อกัน และอื่นๆ เพื่อจัดการกับสถานการณ์ดังกล่าว ทหารผ่านศึก TDD ใช้การจำลอง ซึ่งช่วยแยกแต่ละคลาสโดยการแทนที่อ็อบเจ็กต์ในโมดูลที่ต้องพึ่งพา บทความนี้เป็นเพียงภาพรวมและการแนะนำการทดสอบหน่วยและ TDD ที่ค่อนข้างเรียบง่าย เราจะไม่ลงรายละเอียดเกี่ยวกับโมดูลจำลองและเทคนิค TDD อื่นๆ แนวคิดคือการให้แนวคิดพื้นฐานและหลักการของ TDD และการทดสอบหน่วยที่หวังว่าคุณจะมีในตอนนี้ ต้นฉบับ - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/