รหัสทดสอบทั่วไปนั้นไม่ใช่เรื่องง่าย ถ้าเป็นเช่นนั้นเราจะทำมันมานานแล้วและไม่ได้ทำเรื่องนี้สักหน่อยในช่วง 10-15 ปีที่ผ่านมา หนึ่งในปัญหาที่ใหญ่ที่สุดคือการกำหนดวิธีการทดสอบโค้ดที่เขียนอย่างต่อเนื่องและได้รับการทดสอบอย่างดีและสามารถทดสอบได้โดยไม่ทำลาย encapsulation หลักการของ BDD แนะนำให้เรามุ่งเน้นไปที่พฤติกรรมเกือบทั้งหมดและในบางวิธีดูเหมือนว่าจะแนะนำว่าคุณไม่จำเป็นต้องกังวลเกี่ยวกับรายละเอียดด้านในถึงขนาดใหญ่ แต่สิ่งนี้อาจทำให้การทดสอบค่อนข้างยากหากมี วิธีการส่วนตัวมากมายที่ทำ "สิ่ง" ในวิธีที่ซ่อนเร้นเพราะมันสามารถเพิ่มความซับซ้อนโดยรวมของการทดสอบของคุณเพื่อจัดการกับผลลัพธ์ที่เป็นไปได้ทั้งหมดในระดับสาธารณะมากขึ้น
การเยาะเย้ยสามารถช่วยในระดับหนึ่ง แต่อีกครั้งจะเน้นภายนอกค่อนข้าง การพึ่งพาการฉีดยังสามารถทำงานได้เป็นอย่างดีอีกครั้งด้วย mocks หรือการทดสอบเป็นสองเท่า แต่สิ่งนี้อาจทำให้คุณต้องเปิดเผยองค์ประกอบผ่านอินเทอร์เฟซหรือโดยตรงเพื่อที่คุณอาจต้องการซ่อนอยู่ - นี่เป็นเรื่องจริงโดยเฉพาะถ้าคุณต้องการ มีระดับความปลอดภัยที่หวาดระแวงเกี่ยวกับบางคลาสภายในระบบของคุณ
สำหรับฉันคณะลูกขุนยังคงออกมาว่าจะออกแบบชั้นเรียนของคุณให้สามารถทดสอบได้ง่ายขึ้นหรือไม่ สิ่งนี้สามารถสร้างปัญหาได้หากคุณพบว่าตัวเองต้องการทดสอบใหม่ในขณะที่ยังคงรหัสเดิมไว้ ฉันยอมรับว่าคุณควรจะสามารถทดสอบทุกอย่างในระบบได้ แต่ฉันไม่ชอบความคิดที่เปิดเผย - แม้กระทั่งทางอ้อม - เป็นส่วนตัวของชั้นเรียนเพื่อที่ฉันจะสามารถเขียนการทดสอบสำหรับพวกเขา
สำหรับฉันการแก้ปัญหาคือการใช้วิธีปฏิบัติที่เป็นธรรมและผสมผสานเทคนิคต่าง ๆ เพื่อให้เหมาะสมกับแต่ละสถานการณ์ ฉันใช้การทดสอบจำนวนมากที่ได้รับการสืบทอดสองเท่าเพื่อเปิดเผยคุณสมบัติและพฤติกรรมภายในสำหรับการทดสอบของฉัน ฉันเยาะเย้ยทุกสิ่งที่สามารถแนบไปกับชั้นเรียนของฉันและในกรณีที่จะไม่ลดความปลอดภัยของชั้นเรียนของฉันฉันจะให้วิธีการแทนที่หรือฉีดพฤติกรรมสำหรับวัตถุประสงค์ของการทดสอบ ฉันยังจะพิจารณาให้อินเทอร์เฟซที่ขับเคลื่อนด้วยเหตุการณ์มากขึ้นถ้ามันจะช่วยปรับปรุงความสามารถในการทดสอบโค้ด
ในกรณีที่ฉันพบรหัส"ไม่สามารถทดสอบได้"ฉันจะดูว่าฉันสามารถปรับโครงสร้างใหม่เพื่อให้สามารถทดสอบได้มากขึ้นหรือไม่ ที่ซึ่งคุณมีรหัสส่วนตัวมากมายซ่อนอยู่เบื้องหลังสิ่งต่าง ๆ บ่อยครั้งที่คุณจะพบว่ามีคลาสใหม่ ๆ คลาสเหล่านี้อาจใช้ภายใน แต่มักจะสามารถทดสอบได้อย่างอิสระโดยมีพฤติกรรมส่วนตัวน้อยกว่าและมักจะมีการเข้าถึงและความซับซ้อนน้อยกว่า สิ่งหนึ่งที่ฉันต้องระวังเพื่อหลีกเลี่ยงคือการเขียนรหัสการผลิตด้วยรหัสการทดสอบในตัวมันสามารถดึงดูดให้สร้าง " test lugs " ที่ส่งผลให้เกิดความน่าสะพรึงกลัวเช่นif testing then ...นี้ซึ่งบ่งชี้ว่าปัญหาการทดสอบไม่สมบูรณ์
คุณอาจพบว่าเป็นประโยชน์ในการอ่านหนังสือรูปแบบการทดสอบ xUnitของ Gerard Meszaros ซึ่งครอบคลุมทุกอย่างของสิ่งนี้ในรายละเอียดมากกว่าที่ฉันจะเข้าไปที่นี่ ฉันอาจจะไม่ทำทุกอย่างที่เขาแนะนำ แต่มันจะช่วยชี้แจงสถานการณ์การทดสอบที่ยากขึ้นบางอย่างเพื่อจัดการกับ ในตอนท้ายของวันคุณต้องการที่จะสามารถตอบสนองความต้องการการทดสอบของคุณในขณะที่ยังคงใช้การออกแบบที่คุณต้องการและช่วยให้มีความเข้าใจที่ดีขึ้นของตัวเลือกทั้งหมดเพื่อที่จะตัดสินใจได้ดีขึ้นว่าคุณต้องการประนีประนอมอย่างไร