อ็อบเจ็กต์จำลองมีประโยชน์เมื่อคุณต้องการทดสอบการโต้ตอบระหว่างคลาสภายใต้การทดสอบและอินเทอร์เฟซเฉพาะ
ตัวอย่างเช่นเราต้องการทดสอบเมธอดนั้นsendInvitations(MailServer mailServer)เรียกMailServer.createMessage()เพียงครั้งเดียวและเรียกMailServer.sendMessage(m)ครั้งเดียวเหมือนกันและจะไม่มีการเรียกวิธีอื่นบนMailServerอินเทอร์เฟซ นี่คือเวลาที่เราสามารถใช้วัตถุจำลอง
ด้วยวัตถุจำลองแทนที่จะผ่านของจริงMailServerImplหรือการทดสอบTestMailServerเราสามารถผ่านการจำลองการใช้งานMailServerอินเทอร์เฟซได้ ก่อนที่เราจะผ่านการล้อเลียนMailServerเราจะ "ฝึก" มันเพื่อให้รู้ว่าวิธีใดที่เรียกร้องให้คาดหวังและสิ่งที่จะคืนค่ากลับ ในตอนท้ายวัตถุจำลองยืนยันว่าเมธอดที่คาดหวังทั้งหมดถูกเรียกตามที่คาดไว้
ฟังดูดีในทางทฤษฎี แต่ก็มีข้อเสียบางประการเช่นกัน
ข้อบกพร่องของการเยาะเย้ย
หากคุณมีกรอบการทำงานจำลองคุณจะถูกล่อลวงให้ใช้วัตถุจำลองทุกครั้งที่คุณต้องส่งอินเทอร์เฟซไปยังคลาสภายใต้การทดสอบ วิธีนี้จะทำให้คุณทดสอบการโต้ตอบได้แม้ว่าจะไม่จำเป็นก็ตาม น่าเสียดายที่การทดสอบการโต้ตอบที่ไม่พึงประสงค์ (โดยไม่ได้ตั้งใจ) นั้นไม่ดีเนื่องจากคุณกำลังทดสอบว่าข้อกำหนดเฉพาะถูกนำไปใช้ในลักษณะเฉพาะแทนที่จะนำไปใช้งานนั้นจะให้ผลลัพธ์ที่ต้องการ
นี่คือตัวอย่างใน pseudocode สมมติว่าเราได้สร้างMySorterคลาสขึ้นมาแล้วและเราต้องการทดสอบ:
// the correct way of testing
testSort() {
testList = [1, 7, 3, 8, 2]
MySorter.sort(testList)
assert testList equals [1, 2, 3, 7, 8]
}
// incorrect, testing implementation
testSort() {
testList = [1, 7, 3, 8, 2]
MySorter.sort(testList)
assert that compare(1, 2) was called once
assert that compare(1, 3) was not called
assert that compare(2, 3) was called once
....
}
(ในตัวอย่างนี้เราถือว่าไม่ใช่อัลกอริทึมการเรียงลำดับเฉพาะเช่นการเรียงลำดับด่วนที่เราต้องการทดสอบในกรณีนี้การทดสอบครั้งหลังจะใช้ได้จริง)
ในตัวอย่างที่รุนแรงเช่นนี้เห็นได้ชัดว่าทำไมตัวอย่างหลังจึงผิด เมื่อเราเปลี่ยนการใช้งานMySorterการทดสอบครั้งแรกจะช่วยให้แน่ใจว่าเรายังคงเรียงลำดับอย่างถูกต้องซึ่งเป็นจุดรวมของการทดสอบ - ทำให้เราสามารถเปลี่ยนรหัสได้อย่างปลอดภัย ในทางกลับกันการทดสอบครั้งหลังมักจะหยุดพักและเป็นอันตรายอย่างมาก มันขัดขวางการปรับโครงสร้างใหม่
ล้อเลียนเป็นต้นขั้ว
เฟรมเวิร์กจำลองมักจะอนุญาตให้ใช้งานที่เข้มงวดน้อยกว่าโดยที่เราไม่จำเป็นต้องระบุว่าควรเรียกวิธีการกี่ครั้งและพารามิเตอร์ใด พวกเขาอนุญาตให้สร้างวัตถุจำลองที่ใช้เป็นต้นขั้ว
สมมติว่าเรามีวิธีการsendInvitations(PdfFormatter pdfFormatter, MailServer mailServer)ที่เราต้องการทดสอบ PdfFormatterวัตถุสามารถนำมาใช้ในการสร้างคำเชิญ นี่คือการทดสอบ:
testInvitations() {
// train as stub
pdfFormatter = create mock of PdfFormatter
let pdfFormatter.getCanvasWidth() returns 100
let pdfFormatter.getCanvasHeight() returns 300
let pdfFormatter.addText(x, y, text) returns true
let pdfFormatter.drawLine(line) does nothing
// train as mock
mailServer = create mock of MailServer
expect mailServer.sendMail() called exactly once
// do the test
sendInvitations(pdfFormatter, mailServer)
assert that all pdfFormatter expectations are met
assert that all mailServer expectations are met
}
ในตัวอย่างนี้เราไม่สนใจPdfFormatterวัตถุจริงๆดังนั้นเราแค่ฝึกให้มันรับสายอย่างเงียบ ๆ และส่งคืนค่าผลตอบแทนกระป๋องที่สมเหตุสมผลสำหรับวิธีการทั้งหมดที่sendInvitation()เกิดขึ้นกับการเรียก ณ จุดนี้ เราคิดรายการวิธีการฝึกอบรมนี้ได้อย่างไร? เราทำการทดสอบและเพิ่มวิธีการต่อไปจนกว่าการทดสอบจะผ่าน สังเกตว่าเราได้ฝึกฝนต้นขั้วให้ตอบสนองต่อวิธีการโดยไม่ทราบสาเหตุว่าทำไมจึงต้องเรียกมันเราเพียงแค่เพิ่มทุกสิ่งที่การทดสอบบ่น เรามีความสุขการทดสอบผ่านไป
แต่จะเกิดอะไรขึ้นในภายหลังเมื่อเราเปลี่ยนsendInvitations()หรือคลาสอื่น ๆ ที่sendInvitations()ใช้เพื่อสร้างไฟล์ PDF ที่สวยงามมากขึ้น? การทดสอบของเราล้มเหลวอย่างกะทันหันเพราะตอนนี้มีการPdfFormatterเรียกวิธีการมากขึ้นและเราไม่ได้ฝึกต้นขั้วให้คาดหวัง และโดยปกติแล้วไม่ใช่แค่การทดสอบเดียวที่ล้มเหลวในสถานการณ์เช่นนี้ แต่เป็นการทดสอบใด ๆ ที่เกิดขึ้นกับการใช้sendInvitations()วิธีนี้ไม่ว่าทางตรงหรือทางอ้อม เราต้องแก้ไขการทดสอบเหล่านั้นทั้งหมดโดยเพิ่มการฝึกอบรมให้มากขึ้น โปรดสังเกตด้วยว่าเราไม่สามารถลบวิธีการที่ไม่จำเป็นได้อีกต่อไปเพราะเราไม่รู้ว่าวิธีใดที่ไม่จำเป็น อีกครั้งเป็นอุปสรรคต่อการปรับโครงสร้างใหม่
นอกจากนี้ความสามารถในการอ่านของการทดสอบได้รับความเดือดร้อนอย่างมากมีโค้ดมากมายที่เราไม่ได้เขียนเพราะเราต้องการ แต่เพราะเราต้องทำ ไม่ใช่พวกเราที่ต้องการรหัสนั้น การทดสอบที่ใช้วัตถุจำลองดูซับซ้อนมากและมักจะอ่านยาก การทดสอบควรช่วยให้ผู้อ่านเข้าใจว่าควรใช้ชั้นเรียนภายใต้การทดสอบอย่างไรจึงควรง่ายและตรงไปตรงมา ถ้าอ่านไม่ออกก็ไม่มีใครดูแลมัน ในความเป็นจริงการลบมันง่ายกว่าการดูแลรักษา
จะแก้ไขได้อย่างไร? ได้อย่างง่ายดาย:
- ลองใช้ชั้นเรียนจริงแทนการล้อเลียนทุกครั้งที่ทำได้ ใช้ของจริง
PdfFormatterImpl. หากไม่สามารถทำได้ให้เปลี่ยนคลาสจริงเพื่อให้เป็นไปได้ การไม่สามารถใช้ชั้นเรียนในการทดสอบมักชี้ให้เห็นปัญหาบางอย่างกับชั้นเรียน การแก้ไขปัญหาเป็นสถานการณ์ที่ชนะ - คุณแก้ไขคลาสแล้วและคุณมีการทดสอบที่ง่ายกว่า ในทางกลับกันการไม่แก้ไขและการใช้ล้อเลียนเป็นสถานการณ์ที่ไม่มีทางชนะคุณไม่ได้แก้ไขคลาสจริงและคุณมีการทดสอบที่ซับซ้อนและอ่านได้น้อยกว่าซึ่งขัดขวางการปรับแต่งเพิ่มเติม
- ลองสร้างการใช้งานอินเทอร์เฟซแบบทดสอบอย่างง่ายแทนที่จะล้อเลียนในการทดสอบแต่ละครั้งและใช้คลาสทดสอบนี้ในการทดสอบทั้งหมดของคุณ สร้าง
TestPdfFormatterที่ไม่ทำอะไรเลย ด้วยวิธีนี้คุณสามารถเปลี่ยนได้เพียงครั้งเดียวสำหรับการทดสอบทั้งหมดและการทดสอบของคุณจะไม่เกะกะกับการตั้งค่าที่ยาวนานซึ่งคุณจะต้องฝึกต้นขั้วของคุณ
ทั้งหมดในทุกวัตถุจำลองมีการใช้งานของพวกเขา แต่เมื่อไม่ได้ใช้อย่างระมัดระวังพวกเขามักจะส่งเสริมให้การปฏิบัติที่ไม่ดีการทดสอบรายละเอียดการดำเนินขัดขวาง refactoring และผลิตยากที่จะอ่านและยากที่จะรักษาทดสอบ
สำหรับรายละเอียดบางอย่างเพิ่มเติมเกี่ยวกับข้อบกพร่องของ mocks เห็นวัตถุจำลอง: บกพร่องและกรณีการใช้งาน