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

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

โดยเฉพาะเราจะมีบริการ Web API ที่จะบางมาก ความรับผิดชอบหลักของมันคือการจัดการคำขอ / ตอบกลับเว็บและเรียก API พื้นฐานที่มีตรรกะทางธุรกิจ

ตัวอย่างหนึ่งคือเราวางแผนที่จะสร้างโรงงานที่จะคืนค่าประเภทวิธีการตรวจสอบสิทธิ์ เราไม่จำเป็นต้องให้อินเทอร์เฟซสืบทอดเนื่องจากเราไม่ได้คาดหวังว่ามันจะเป็นสิ่งอื่นนอกเหนือจากรูปแบบที่เป็นรูปธรรม อย่างไรก็ตามหากต้องการทดสอบบริการ Web API เราจะต้องจำลองโรงงานนี้

นี่หมายถึงว่าเราออกแบบคลาสคอนโทรลเลอร์ API ของเว็บเพื่อยอมรับ DI (ผ่าน Constructor หรือ Setter) ซึ่งหมายความว่าเราออกแบบส่วนของคอนโทรลเลอร์เพียงเพื่อให้ DI และใช้อินเตอร์เฟสที่เราไม่ต้องการหรือเราใช้ เฟรมเวิร์กของบุคคลที่สามอย่าง Ninject เพื่อหลีกเลี่ยงการออกแบบคอนโทรลเลอร์ในลักษณะนี้ แต่เราจะต้องสร้างอินเทอร์เฟซ

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

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

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

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

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

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

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

มันไม่ง่ายอย่างที่คุณคิด มาทำลายมันกันเถอะ

• การเขียนแบบทดสอบหน่วยเป็นสิ่งที่ดีอย่างแน่นอน

แต่!

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

• webapi ที่ 'บางมาก' ของคุณไม่เหมือนกรณีที่ดีที่สุดสำหรับการทดสอบหน่วย

• การเปลี่ยนรหัสและการทดสอบในเวลาเดียวกันเป็นสิ่งที่ไม่ดี

ฉันขอแนะนำวิธีต่อไปนี้:

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

2. ตรวจสอบให้แน่ใจว่าโค้ดใหม่นั้นสามารถทดสอบได้และมีการทดสอบหน่วยและการรวมระบบ

3. ตรวจสอบให้แน่ใจว่าเชน CI ของคุณทำการทดสอบหลังจากสร้างและปรับใช้

เมื่อคุณตั้งค่าสิ่งเหล่านั้นจากนั้นเริ่มคิดเกี่ยวกับการปรับโครงสร้างโครงการดั้งเดิมเพื่อการทดสอบ

หวังว่าทุกคนจะได้เรียนรู้บทเรียนจากกระบวนการและมีความคิดที่ดีว่าต้องการการทดสอบมากที่สุดวิธีที่คุณต้องการจัดโครงสร้างและมูลค่าที่นำมาสู่ธุรกิจ

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

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

การออกแบบรหัสให้ทดสอบได้โดยเนื้อแท้นั้นไม่ใช่กลิ่นรหัส ในทางตรงกันข้ามมันเป็นสัญญาณของการออกแบบที่ดี มีรูปแบบการออกแบบที่เป็นที่รู้จักและใช้กันอย่างแพร่หลายหลายรูปแบบตามรูปแบบนี้ (เช่น Model-View-Presenter) ซึ่งให้การทดสอบที่ง่าย (ง่ายกว่า) ซึ่งเป็นข้อได้เปรียบที่ยิ่งใหญ่

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

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

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

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

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

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

ฉันมีปัญหากับการยืนยัน (ไม่ยืนยัน) คุณทำ:

เพื่อทดสอบหน่วยบริการ Web API เราจะต้องจำลองโรงงานนี้

ไม่จำเป็นต้องเป็นเรื่องจริง มีหลายวิธีในการเขียนการทดสอบมีและมีวิธีการที่จะเขียนทดสอบหน่วยที่ไม่เกี่ยวข้องกับ mocks ที่สำคัญมีการทดสอบประเภทอื่น ๆเช่นการทดสอบการทำงานหรือการรวม หลายครั้งที่มันเป็นไปได้ที่จะหา "ตะเข็บทดสอบ" ที่เป็น "อินเตอร์เฟซ" interfaceที่ไม่ได้เป็นภาษาโปรแกรม

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

• ฉันจะเคยต้องการที่จะเขียนเว็บ API บางกว่าที่แตกต่างกัน API?
• ฉันสามารถลดการทำสำเนารหัสระหว่าง Web API และ API พื้นฐานได้หรือไม่ หนึ่งสามารถสร้างในแง่ของอื่น ๆ ?
• ฉันสามารถปฏิบัติต่อทั้ง Web API และ API พื้นฐานเป็นหน่วย "กล่องดำ" เดียวและมีความหมายอย่างมีนัยสำคัญเกี่ยวกับวิธีการทำงานของสิ่งทั้งหมด?
• หากต้องเปลี่ยน Web API ด้วยการใช้งานใหม่ในอนาคตเราจะดำเนินการอย่างไร
• หาก Web API ถูกแทนที่ด้วยการใช้งานใหม่ในอนาคตลูกค้าของ Web API จะสามารถสังเกตเห็นได้หรือไม่ ถ้าเป็นเช่นนั้นได้อย่างไร

การยืนยันที่ไม่พร้อมเพรียงอีกอย่างที่คุณทำนั้นเกี่ยวกับ DI:

เราออกแบบคลาสคอนโทรลเลอร์ API ของเว็บเพื่อยอมรับ DI (ผ่าน Constructor หรือ Setter) ซึ่งหมายความว่าเรากำลังออกแบบส่วนของคอนโทรลเลอร์เพื่อให้ DI และใช้อินเทอร์เฟซที่เราไม่ต้องการหรือเราใช้บุคคลที่สาม เฟรมเวิร์กเช่น Ninject เพื่อหลีกเลี่ยงการออกแบบตัวควบคุมในลักษณะนี้ แต่เราจะยังต้องสร้างส่วนต่อประสาน

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

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

คุณโชคดีเพราะนี่เป็นโครงการใหม่ ฉันพบว่า Test Driven Design ทำงานได้ดีมากในการเขียนโค้ดที่ดี (ซึ่งเป็นสาเหตุที่เราทำในตอนแรก)

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

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

พิจารณามัน โดยเฉพาะอย่างยิ่งกับการตรวจสอบเพื่อน จากประสบการณ์ของฉันการลงทุนเวลาและความพยายามจะกลับมาอย่างรวดเร็ว

หากคุณต้องการแก้ไขรหัสนั่นคือกลิ่นรหัส

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

โค้ด Good (Clean) แบ่งงานออกเป็นส่วนย่อย ๆ ที่เข้าใจได้ง่ายในทันที (หรืออย่างน้อยก็ดูดี) การทดสอบส่วนเล็ก ๆ เหล่านี้เป็นเรื่องง่าย ฉันยังสามารถเขียนการทดสอบที่ทดสอบเฉพาะ codebase อย่างง่ายดายคล้ายกันหากฉันค่อนข้างมั่นใจเกี่ยวกับส่วนย่อย

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

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

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

คุณพูด

เราวางแผนที่จะสร้างโรงงานที่จะส่งคืนประเภทวิธีการตรวจสอบสิทธิ์ เราไม่จำเป็นต้องให้อินเทอร์เฟซสืบทอดเนื่องจากเราไม่ได้คาดหวังว่ามันจะเป็นสิ่งอื่นนอกเหนือจากรูปแบบที่เป็นรูปธรรม อย่างไรก็ตามหากต้องการทดสอบบริการ Web API เราจะต้องจำลองโรงงานนี้

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

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

ในสาขาวิศวกรรมทุกสาขาที่ฉันนึกออกมีเพียงหนทางเดียวที่จะบรรลุถึงระดับคุณภาพที่ดีหรือสูงกว่า:

เพื่อบัญชีสำหรับการตรวจสอบ / ทดสอบในการออกแบบ

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

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

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

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

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

โดยสังเขป:

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

ตัวอย่างหนึ่งคือเราวางแผนที่จะสร้างโรงงานที่จะคืนค่าประเภทวิธีการตรวจสอบสิทธิ์ เราไม่จำเป็นต้องให้อินเทอร์เฟซสืบทอดเนื่องจากเราไม่ได้คาดหวังว่ามันจะเป็นสิ่งอื่นนอกเหนือจากรูปแบบที่เป็นรูปธรรม

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

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

นี่หมายถึงว่าเราออกแบบคลาสคอนโทรลเลอร์ API ของเว็บเพื่อยอมรับ DI (ผ่าน Constructor หรือ Setter) ซึ่งหมายความว่าเราออกแบบส่วนของคอนโทรลเลอร์เพียงเพื่อให้ DI และใช้อินเตอร์เฟสที่เราไม่ต้องการหรือเราใช้ เฟรมเวิร์กของบุคคลที่สามอย่าง Ninject เพื่อหลีกเลี่ยงการออกแบบคอนโทรลเลอร์ในลักษณะนี้ แต่เราจะต้องสร้างอินเทอร์เฟซ

ลองดูความแตกต่างระหว่างทดสอบได้:

public class MyController : Controller
{
    private readonly IMyDependency _thing;

    public MyController(IMyDependency thing)
    {
        _thing = thing;
    }
}

และคอนโทรลเลอร์ที่ไม่สามารถทดสอบได้:

public class MyController : Controller
{
}

ตัวเลือกเดิมมีรหัสพิเศษ 5 บรรทัดโดยสองบรรทัดนี้สามารถสร้างอัตโนมัติได้โดย Visual Studio เมื่อคุณตั้งค่ากรอบการฉีดการพึ่งพาเพื่อแทนที่ชนิดที่เป็นรูปธรรมสำหรับIMyDependencyณ รันไทม์ - ซึ่งสำหรับเฟรมเวิร์ก DI ที่ดีใด ๆ ก็เป็นอีกโค้ดหนึ่งบรรทัด - ทุกอย่างใช้งานได้ดียกเว้นตอนนี้คุณสามารถเยาะเย้ยและทดสอบตัวควบคุมของคุณ .

รหัสพิเศษ 6 บรรทัดเพื่อให้สามารถทดสอบได้ ... และเพื่อนร่วมงานของคุณกำลังเถียงกันว่า "ทำงานมากเกินไป" หรือไม่? อาร์กิวเมนต์นั้นไม่ได้บินไปกับฉันและมันก็ไม่ควรบินไปกับคุณ

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

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

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

มีแนวโน้มที่จะใช้ฟังก์ชั่นที่บริสุทธิ์มากที่สุดเท่าที่จะทำได้ (แอพที่ไม่มีเซิร์ฟเวอร์) การทดสอบหน่วยช่วยให้ฉันแยกสถานะและเขียนฟังก์ชั่นล้วน ๆ

โดยเฉพาะเราจะมีบริการ Web API ที่จะบางมาก ความรับผิดชอบหลักของมันคือการจัดการคำขอ / ตอบกลับเว็บและเรียก API พื้นฐานที่มีตรรกะทางธุรกิจ

เขียนการทดสอบหน่วยสำหรับ API พื้นฐานก่อนและถ้าคุณมีเวลาในการพัฒนาที่เพียงพอคุณต้องเขียนการทดสอบสำหรับบริการเว็บ API ที่บางด้วยเช่นกัน

TL; DR, การทดสอบหน่วยช่วยปรับปรุงคุณภาพของรหัสและช่วยให้การเปลี่ยนแปลงในอนาคตกับความเสี่ยงของรหัสฟรี นอกจากนี้ยังปรับปรุงความสามารถในการอ่านรหัส ใช้การทดสอบแทนความคิดเห็นเพื่อให้ประเด็นของคุณ

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

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

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