ฉันได้ทำลายการทดสอบหน่วยหลายครั้งที่ผ่านมาเมื่อฉันผ่านไปและปรับโครงสร้างใหม่เพื่อให้แห้งมากขึ้น- เจตนาของการทดสอบแต่ละครั้งไม่ชัดเจนอีกต่อไป ดูเหมือนว่าจะมีการแลกเปลี่ยนระหว่างความสามารถในการอ่านและการบำรุงรักษาของการทดสอบ ถ้าฉันทิ้งรหัสที่ซ้ำกันไว้ในการทดสอบหน่วยก็จะอ่านได้ง่ายขึ้น แต่ถ้าฉันเปลี่ยนSUTฉันจะต้องติดตามและเปลี่ยนรหัสที่ซ้ำกันแต่ละชุด
คุณยอมรับว่ามีการแลกเปลี่ยนนี้หรือไม่? ถ้าเป็นเช่นนั้นคุณต้องการให้การทดสอบของคุณอ่านได้หรือบำรุงรักษาได้?
คำตอบ:
รหัสซ้ำเป็นกลิ่นในรหัสทดสอบหน่วยเช่นเดียวกับรหัสอื่น ๆ หากคุณมีโค้ดที่ซ้ำกันในการทดสอบจะทำให้ยากต่อการ refactor โค้ดการนำไปใช้งานเนื่องจากคุณมีจำนวนการทดสอบที่ไม่ได้สัดส่วนที่จะอัปเดต การทดสอบควรช่วยให้คุณ refactor ด้วยความมั่นใจแทนที่จะเป็นภาระใหญ่ที่ขัดขวางการทำงานของคุณกับโค้ดที่กำลังทดสอบ
หากการทำสำเนาถูกในการติดตั้งการตั้งค่าการพิจารณาการใช้มากขึ้นของsetUpวิธีการหรือให้มากขึ้น (หรือความยืดหยุ่นมากขึ้น) วิธีการสร้าง
หากการทำซ้ำอยู่ในรหัสที่จัดการกับมทส. ให้ถามตัวเองว่าเหตุใดการทดสอบ "หน่วย" หลายรายการจึงใช้ฟังก์ชันเดียวกันทั้งหมด
หากการทำสำเนาที่อยู่ในการยืนยันแล้วบางทีคุณอาจจะต้องมีการยืนยันที่กำหนดเอง ตัวอย่างเช่นหากการทดสอบหลายรายการมีข้อความยืนยันเช่น:
assertEqual('Joe', person.getFirstName())
assertEqual('Bloggs', person.getLastName())
assertEqual(23, person.getAge())
บางทีคุณอาจต้องใช้assertPersonEqualวิธีการเดียวจึงจะสามารถเขียนassertPersonEqual(Person('Joe', 'Bloggs', 23), person)ได้ (หรือบางทีคุณอาจต้องโอเวอร์โหลดตัวดำเนินการความเท่าเทียมกันPerson)
ดังที่คุณพูดถึงสิ่งสำคัญคือต้องอ่านโค้ดทดสอบได้ โดยเฉพาะอย่างยิ่งสิ่งสำคัญคือเจตนาของการทดสอบจะต้องชัดเจน ฉันพบว่าหากการทดสอบส่วนใหญ่มีลักษณะเหมือนกัน (เช่นสามในสี่ของบรรทัดเหมือนกันหรือแทบจะเหมือนกัน) ก็ยากที่จะระบุและรับรู้ความแตกต่างที่มีนัยสำคัญโดยไม่ต้องอ่านและเปรียบเทียบอย่างรอบคอบ ดังนั้นฉันจึงพบว่าการปรับโครงสร้างใหม่เพื่อลบการทำซ้ำช่วยให้สามารถอ่านได้เนื่องจากทุกบรรทัดของวิธีการทดสอบทั้งหมดเกี่ยวข้องโดยตรงกับวัตถุประสงค์ของการทดสอบ สิ่งนี้มีประโยชน์มากสำหรับผู้อ่านมากกว่าการรวมกันแบบสุ่มของบรรทัดที่เกี่ยวข้องโดยตรงและบรรทัดที่เป็นเพียงต้นแบบ
ที่กล่าวว่าบางครั้งการทดสอบกำลังใช้สถานการณ์ที่ซับซ้อนซึ่งคล้ายคลึงกัน แต่ยังคงแตกต่างกันอย่างมีนัยสำคัญและเป็นการยากที่จะหาวิธีที่ดีในการลดความซ้ำซ้อน ใช้สามัญสำนึก: หากคุณรู้สึกว่าการทดสอบสามารถอ่านได้และทำให้เจตนาของพวกเขาชัดเจนและคุณรู้สึกสบายใจที่อาจจำเป็นต้องอัปเดตมากกว่าจำนวนการทดสอบที่น้อยที่สุดในทางทฤษฎีเมื่อทำการปรับเปลี่ยนรหัสที่เรียกใช้โดยการทดสอบให้ยอมรับความไม่สมบูรณ์และย้าย ไปสู่สิ่งที่มีประสิทธิผลมากขึ้น คุณสามารถกลับมาปรับแต่งการทดสอบในภายหลังได้ทุกเมื่อเมื่อแรงบันดาลใจหยุดลง!
ความสามารถในการอ่านสำคัญกว่าสำหรับการทดสอบ หากการทดสอบล้มเหลวคุณต้องการให้ปัญหาชัดเจน นักพัฒนาไม่ควรต้องลุยกับโค้ดทดสอบที่มีการพิจารณาปัจจัยจำนวนมากเพื่อตัดสินว่าอะไรล้มเหลว คุณไม่ต้องการให้โค้ดทดสอบของคุณซับซ้อนจนต้องเขียนแบบทดสอบหน่วย
อย่างไรก็ตามการกำจัดการทำซ้ำมักจะเป็นสิ่งที่ดีตราบเท่าที่ไม่ได้ปิดบังอะไรและการกำจัดการทำซ้ำในการทดสอบของคุณอาจนำไปสู่ API ที่ดีกว่า ตรวจสอบให้แน่ใจว่าคุณไม่ผ่านจุดที่ผลตอบแทนลดลง
รหัสการติดตั้งและการทดสอบเป็นสัตว์ที่แตกต่างกันและกฎการแยกตัวประกอบจะใช้แตกต่างกันไป
รหัสหรือโครงสร้างที่ซ้ำกันมักจะเป็นกลิ่นในโค้ดการนำไปใช้งาน เมื่อคุณเริ่มมีต้นแบบในการนำไปใช้งานคุณจำเป็นต้องแก้ไขนามธรรมของคุณ
ในทางกลับกันรหัสทดสอบจะต้องรักษาระดับการทำซ้ำ การทำซ้ำในรหัสทดสอบทำให้บรรลุเป้าหมายสองประการ:
ฉันมักจะเพิกเฉยต่อการทำซ้ำโค้ดทดสอบเล็กน้อยตราบใดที่วิธีทดสอบแต่ละวิธียังคงสั้นกว่าประมาณ 20 บรรทัด ฉันชอบเมื่อจังหวะการตั้งค่ารัน - ตรวจสอบปรากฏในวิธีการทดสอบ
เมื่อการทำซ้ำเกิดขึ้นในส่วน "ตรวจสอบ" ของการทดสอบมักจะเป็นประโยชน์ในการกำหนดวิธีการยืนยันแบบกำหนดเอง แน่นอนว่าวิธีการเหล่านั้นยังคงต้องทดสอบความสัมพันธ์ที่ระบุไว้อย่างชัดเจนซึ่งสามารถทำให้เห็นได้ชัดในชื่อวิธีการ: assertPegFitsInHole-> ดีassertPegIsGood-> ไม่ดี
เมื่อวิธีการทดสอบยาวขึ้นและซ้ำซากบางครั้งฉันพบว่ามีประโยชน์ในการกำหนดเทมเพลตการทดสอบการกรอกข้อมูลในช่องว่างที่ใช้พารามิเตอร์ไม่กี่ตัว จากนั้นวิธีการทดสอบจริงจะลดลงเป็นการเรียกใช้วิธีเทมเพลตด้วยพารามิเตอร์ที่เหมาะสม
สำหรับหลายสิ่งหลายอย่างในการเขียนโปรแกรมและการทดสอบยังไม่มีคำตอบที่ชัดเจน คุณต้องพัฒนารสชาติและวิธีที่ดีที่สุดคือการทำผิด
ฉันเห็นด้วย. การแลกเปลี่ยนมีอยู่ แต่แตกต่างกันในสถานที่ต่างๆ
ฉันมีแนวโน้มที่จะ refactor รหัสที่ซ้ำกันสำหรับการตั้งค่าสถานะ แต่มีโอกาสน้อยที่จะ refactor ส่วนของการทดสอบที่ใช้โค้ดจริงๆ ที่กล่าวว่าหากการใช้รหัสมักใช้รหัสหลายบรรทัดฉันอาจคิดว่านั่นเป็นกลิ่นและเปลี่ยนรหัสจริงภายใต้การทดสอบ และจะช่วยเพิ่มความสามารถในการอ่านและการบำรุงรักษาของทั้งโค้ดและการทดสอบ
เจย์ทุ่งวลีติดปากว่า "มี DSL ควรจะชื้นไม่แห้ง" ซึ่งชื้นวิธีการบรรยายและวลีที่มีความหมาย ฉันคิดว่าเช่นเดียวกันกับการทดสอบด้วย เห็นได้ชัดว่าการทำซ้ำมากเกินไปไม่ดี แต่การลบการทำซ้ำโดยเสียค่าใช้จ่ายทั้งหมดนั้นเลวร้ายยิ่งกว่า การทดสอบควรทำตามข้อกำหนดที่เปิดเผยโดยเจตนา ตัวอย่างเช่นหากคุณระบุคุณลักษณะเดียวกันจากมุมต่างๆหลายมุมก็คาดว่าจะมีการทำซ้ำจำนวนหนึ่ง
ฉันชอบ rspec เพราะสิ่งนี้:
มี 2 สิ่งที่จะช่วยได้ -
กลุ่มตัวอย่างที่ใช้ร่วมกันสำหรับการทดสอบพฤติกรรมทั่วไป
คุณสามารถกำหนดชุดการทดสอบจากนั้น "รวม" ที่กำหนดไว้ในการทดสอบจริงของคุณ
บริบทที่ซ้อนกัน
โดยพื้นฐานแล้วคุณสามารถมีเมธอด 'การตั้งค่า' และ 'การฉีกขาด' สำหรับชุดย่อยของการทดสอบของคุณโดยเฉพาะไม่ใช่แค่ทุกรายการในชั้นเรียน
ยิ่ง. NET / Java / กรอบการทดสอบอื่น ๆ ใช้วิธีการเหล่านี้เร็วเท่าไหร่ก็ยิ่งดี (หรือคุณสามารถใช้ IronRuby หรือ JRuby เพื่อเขียนการทดสอบของคุณซึ่งโดยส่วนตัวแล้วฉันคิดว่าเป็นตัวเลือกที่ดีกว่า)
ฉันรู้สึกว่ารหัสทดสอบต้องใช้วิศวกรรมในระดับใกล้เคียงกันซึ่งโดยปกติจะใช้กับรหัสการผลิต อาจมีข้อโต้แย้งที่เอื้อต่อการอ่านได้อย่างแน่นอนและฉันก็ยอมรับว่าเป็นสิ่งสำคัญ
อย่างไรก็ตามจากประสบการณ์ของฉันฉันพบว่าการทดสอบที่มีเนื้อหาดีนั้นอ่านและเข้าใจได้ง่ายกว่า หากมีการทดสอบ 5 รายการที่แต่ละรายการมีลักษณะเหมือนกันยกเว้นตัวแปรเดียวที่เปลี่ยนไปและการยืนยันในตอนท้ายอาจเป็นเรื่องยากมากที่จะพบว่ารายการที่แตกต่างกันนั้นคืออะไร ในทำนองเดียวกันถ้ามีการแยกตัวประกอบเพื่อให้มองเห็นเฉพาะตัวแปรที่เปลี่ยนแปลงและการยืนยันก็ง่ายที่จะทราบว่าการทดสอบกำลังทำอะไรอยู่ในทันที
การค้นหาระดับนามธรรมที่เหมาะสมเมื่อทำการทดสอบอาจเป็นเรื่องยากและฉันรู้สึกว่ามันคุ้มค่าที่จะทำ
ฉันไม่คิดว่าจะมีความสัมพันธ์ระหว่างโค้ดที่ซ้ำกันและอ่านได้มากกว่า ฉันคิดว่ารหัสทดสอบของคุณควรจะดีพอ ๆ กับรหัสอื่น ๆ ของคุณ รหัสที่ไม่ทำซ้ำนั้นสามารถอ่านได้มากขึ้นจากนั้นโค้ดที่ซ้ำกันเมื่อทำได้ดี
ตามหลักการแล้วการทดสอบหน่วยไม่ควรเปลี่ยนแปลงมากนักเมื่อมีการเขียนดังนั้นฉันจะพึ่งพาความสามารถในการอ่าน
การมีการทดสอบหน่วยให้แยกออกจากกันมากที่สุดยังช่วยให้การทดสอบมุ่งเน้นไปที่ฟังก์ชันเฉพาะที่พวกเขากำหนดเป้าหมายไว้
ด้วยเหตุนี้ฉันจึงมักจะพยายามใช้โค้ดบางส่วนที่ฉันไขลานซ้ำแล้วซ้ำอีกเช่นรหัสการตั้งค่าที่เหมือนกันทุกประการในชุดการทดสอบ
"ปรับโครงสร้างใหม่เพื่อให้แห้งมากขึ้น - เจตนาของการทดสอบแต่ละครั้งไม่ชัดเจนอีกต่อไป"
ดูเหมือนว่าคุณมีปัญหาในการปรับโครงสร้างใหม่ ฉันแค่คาดเดา แต่ถ้ามันชัดเจนน้อยลงไม่ได้หมายความว่าคุณยังมีงานต้องทำอีกมากเพื่อให้คุณมีการทดสอบที่สวยงามพอสมควรซึ่งชัดเจนอย่างสมบูรณ์?
นั่นเป็นเหตุผลว่าทำไมการทดสอบจึงเป็นคลาสย่อยของ UnitTest ดังนั้นคุณจึงสามารถออกแบบชุดทดสอบที่ดีที่ถูกต้องตรวจสอบได้ง่ายและชัดเจน
ในสมัยก่อนเรามีเครื่องมือทดสอบที่ใช้ภาษาโปรแกรมต่างๆ เป็นการยาก (หรือเป็นไปไม่ได้) ในการออกแบบการทดสอบที่ถูกใจและใช้งานง่าย
คุณมีพลังเต็มที่ไม่ว่าคุณจะใช้ภาษาใด - Python, Java, C # - ดังนั้นจงใช้ภาษานั้นให้ดี คุณสามารถบรรลุรหัสทดสอบที่ดูดีชัดเจนและไม่ซ้ำซ้อนเกินไป ไม่มีการแลกเปลี่ยน