จากมุมมองของ TDD ฉันเป็นคนไม่ดีถ้าฉันทดสอบกับจุดสิ้นสุดสดแทนการเยาะเย้ย

ฉันติดตาม TDD อย่างเคร่งครัด โครงการของฉันมักจะมี 85% หรือครอบคลุมการทดสอบที่ดีขึ้นพร้อมกรณีทดสอบที่มีความหมาย

ฉันทำงานมากกับHBaseและอินเทอร์เฟซไคลเอนต์หลัก HTable เป็นความเจ็บปวดที่แท้จริงในการเยาะเย้ย ฉันใช้เวลาในการเขียนการทดสอบหน่วยของฉันนานกว่า 3 ถึง 4 เท่ากว่าการเขียนการทดสอบที่ใช้จุดปลายจริง

ฉันรู้ว่าในทางปรัชญาการทดสอบที่ใช้ mocks ควรให้ความสำคัญมากกว่าการทดสอบที่ใช้จุดสิ้นสุดแบบสด แต่การเยาะเย้ยHTableเป็นความเจ็บปวดที่ร้ายแรงและฉันไม่แน่ใจว่าจริง ๆ แล้วมันมีข้อได้เปรียบมากกว่าการทดสอบกับ HBase แบบสด

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

ตอนนี้ฉันเขียนการทดสอบจุดปลายสดและการทดสอบตามแบบจำลองสำหรับชั้นเรียนของฉันทั้งหมด ฉันชอบที่จะขุด mocks แต่ฉันไม่ต้องการให้มีคุณภาพลดลงเป็นผล

คุณคิดอย่างไร?

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

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

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

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

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

ในเชิงปรัชญาการทดสอบที่ใช้ mocks ควรให้ความสำคัญมากกว่าการทดสอบที่ใช้จุดสิ้นสุดจริง

ฉันคิดว่าอย่างน้อยที่สุดนั่นเป็นประเด็นถกเถียงอย่างต่อเนื่องในปัจจุบัน ระหว่างผู้สนับสนุน TDD

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

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

เป็นกรณีหลังที่คุณกำลังทำเมื่อคุณทดสอบกับฐานข้อมูลท้องถิ่น 'สด'; การใช้ htable เริ่มต้นขึ้นและใช้การตรวจสอบความถูกต้องที่ครอบคลุมของสัญญา interfacve มากกว่าที่คุณคิดว่าจะเขียนด้วยมือ

น่าเสียดายที่การใช้การทดสอบแบบจำลองเป็นหลักคือการทดสอบที่:

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

แน่นอนการทดสอบดังกล่าวควรถูกลบออกเมื่อเห็น

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

ฉันเห็นด้วยอย่างสมบูรณ์กับการตอบสนองของ guillaume31 ไม่เคยล้อเลียนประเภทที่คุณไม่ได้เป็นเจ้าของ!

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

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

ลองดูที่รูปแบบการสนทนานี้ Ian Cooper: http://vimeo.com/68375232เขาพูดเกี่ยวกับสถาปัตยกรรมหกเหลี่ยมและการทดสอบเขาพูดถึงเวลาและสิ่งที่จะเยาะเย้ยการพูดที่ได้รับแรงบันดาลใจจริงๆที่ตอบคำถามมากมายเช่นคุณเกี่ยวกับ TDD จริง .

TL; DR - วิธีที่ฉันเห็นมันขึ้นอยู่กับว่าคุณต้องใช้ความพยายามมากแค่ไหนในการทดสอบและจะดีกว่าหรือไม่ที่จะใช้มันในระบบจริงของคุณ

รุ่นยาว:

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

ตัวอย่างเช่นค่าหลักที่ฉันได้รับจากการทดสอบคือ:

• ความน่าเชื่อถือ (และความเร็วในการพัฒนา): refactor code / รวมเฟรมเวิร์กใหม่ / สลับส่วนประกอบ / พอร์ตไปยังแพลตฟอร์มที่แตกต่างกันมั่นใจได้ว่าสิ่งต่างๆยังใช้งานได้
• ข้อเสนอแนะการออกแบบ: ความคิดเห็นคลาสสิก TDD / BDD "ใช้รหัสของคุณ" ในอินเทอร์เฟซต่ำ / ระดับกลาง

การทดสอบกับอุปกรณ์ถ่ายทอดสดควรยังคงให้สิ่งเหล่านี้

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

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

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

จากมุมมองการทดสอบมีข้อกำหนดบางประการที่จำเป็นต้องมี:

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

นั่นเป็นความท้าทายที่ยิ่งใหญ่เมื่อเชื่อมต่อกับแหล่งใด ๆ ที่รักษาสถานะภายนอกการทดสอบของคุณ ไม่ใช่ TDD ที่ "บริสุทธิ์" แต่ลูกเรือ Ruby on Rails แก้ไขปัญหานี้ในแบบที่อาจจะปรับให้เหมาะกับวัตถุประสงค์ของคุณ กรอบการทดสอบทางรถไฟทำงานในลักษณะนี้:

• การกำหนดค่าการทดสอบถูกเลือกโดยอัตโนมัติเมื่อเรียกใช้การทดสอบหน่วย
• ฐานข้อมูลถูกสร้างและเริ่มต้นเมื่อเริ่มการทดสอบหน่วย
• ฐานข้อมูลถูกลบหลังจากเรียกใช้การทดสอบหน่วย
• หากใช้ SqlLite การกำหนดค่าการทดสอบจะใช้ฐานข้อมูล RAM

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

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

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