วิธีหลีกเลี่ยงความจำเป็นในการทดสอบหน่วยวิธีส่วนตัว

15

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

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

ฉันชอบการเยาะเย้ยวิธีส่วนตัวเมื่อทำการทดสอบวิธีสาธารณะและการล้อเลียนการอ้างอิงภายนอกเมื่อทำการทดสอบวิธีส่วนตัว

ฉันบ้าเหรอ?

unit-testing mocking

— Fran Sevillano
แหล่งที่มา

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

— GordonM

24

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

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

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

ดังนั้น - อย่าจำลองวิธีการส่วนตัวของคุณ ใช้พวกมันเพื่อทำความเข้าใจกับสิ่งที่คุณต้องทดสอบเพื่อมอบความครอบคลุมที่ดีของฟังก์ชันที่คุณมี โดยเฉพาะอย่างยิ่งในระดับการทดสอบหน่วย

— โทมัสโอเวนส์
แหล่งที่มา

1

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

— Ewan

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

— Fran Sevillano

8

@FranSevillano ถ้าคุณต้องพูดไม่ออกหรือเยาะเย้ยฉันจะมองการออกแบบโดยรวมของคุณ บางสิ่งบางอย่างรู้สึกปิด

— โธมัสโอเวนส์

เครื่องมือครอบคลุมรหัสช่วยในเรื่องนี้

— Andy

5

@FranSevillano: ไม่มีเหตุผลที่ดีมากมายสำหรับชั้นเรียนที่ทำสิ่งหนึ่งที่มีการพึ่งพามากมาย หากคุณมีการพึ่งพามากมายคุณอาจมีคลาสพระเจ้า

— Mooing Duck

4

ฉันคิดว่านี่เป็นความคิดที่แย่มาก

ปัญหาในการสร้างการทดสอบหน่วยของสมาชิกส่วนตัวก็คือมันไม่เหมาะกับวงจรชีวิตของผลิตภัณฑ์

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

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

ผมแนะนำให้คุณ:

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

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

— Lewis Pringle
แหล่งที่มา

6

ฉันไม่เห็นด้วย. IMO นี้ถูกต้อง 100% สำหรับการทดสอบการรวม แต่ด้วยการทดสอบหน่วยสิ่งต่าง ๆ เป้าหมายของการทดสอบหน่วยคือการหาจุดที่บั๊กแคบให้เพียงพอเพื่อให้คุณสามารถแก้ไขได้อย่างรวดเร็ว ฉันพบว่าตัวเองมักจะอยู่ในสถานการณ์เช่นนี้: ฉันมีวิธีการสาธารณะน้อยมากเพราะนั่นคือค่านิยมหลักของชั้นเรียนของฉัน (อย่างที่คุณบอกว่าควรทำ) อย่างไรก็ตามฉันยังหลีกเลี่ยงการเขียนวิธี 400 บรรทัดทั้งสาธารณะและส่วนตัว ดังนั้นวิธีการไม่กี่สาธารณะของฉันสามารถบรรลุเป้าหมายของพวกเขาด้วยความช่วยเหลือของวิธีการส่วนตัวหลายสิบ ระบุรหัสมากเกินไปที่จะ "แก้ไขได้อย่างรวดเร็ว" ฉันจะต้องเริ่มต้นการดีบักเกอร์ ฯลฯ ..

— marstato

6

@marstato: ข้อเสนอแนะ: เริ่มเขียนการทดสอบก่อนและเปลี่ยนความคิดของคุณเกี่ยวกับ unittests: พวกเขาไม่พบข้อบกพร่อง แต่ตรวจสอบว่ารหัสทำงานตามที่นักพัฒนาตั้งใจ

— ทิโมธี Truckle

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

— Lewis Pringle

@marstato "เป้าหมายของการทดสอบหน่วยคือการหาจุดที่บั๊ก" - นั่นเป็นความเข้าใจผิดที่นำไปสู่คำถามของ OP เป้าหมายของการทดสอบหน่วยคือการตรวจสอบพฤติกรรมที่ตั้งใจ (และจัดทำเป็นเอกสาร) ของ API

— StackOverthrow

4

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

— Ben

3

UnitTests ทดสอบ พฤติกรรมที่สังเกตได้ของสาธารณะไม่ใช่รหัสโดยที่ "สาธารณะ" หมายถึง: คืนค่าและสื่อสารกับการอ้างอิง

"หน่วย" คือรหัสใด ๆ ที่แก้ปัญหาเดียวกัน (หรือแม่นยำกว่า: มีเหตุผลเดียวกันในการเปลี่ยนแปลง) นั่นอาจเป็นวิธีการเดียวหรือหลายคลาส

เหตุผลหลักว่าทำไมคุณไม่ต้องการที่จะทดสอบprivate methodsคือพวกเขามีรายละเอียดการดำเนินงานและคุณอาจต้องการที่จะเปลี่ยนพวกเขาในช่วงrefactoring (ปรับปรุงรหัสของคุณโดยใช้ OO-หลักการโดยไม่มีการเปลี่ยนแปลงการทำงาน) ตรงนี้เป็นเมื่อคุณไม่ต้องการให้ unittests ของคุณเปลี่ยนเพื่อให้พวกเขาสามารถรับประกันพฤติกรรมของ CuT ของคุณที่ไม่เปลี่ยนแปลงระหว่างการ refactoring

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

ฉันมักจะพบสิ่งที่ตรงกันข้าม: ยิ่งชั้นเรียนเล็กลง (ยิ่งมีความรับผิดชอบน้อยลง) ยิ่งพึ่งพาน้อยลงและยิ่งง่ายขึ้นก็คือ unittests ทั้งในการเขียนและอ่าน

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

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

— ทิโมธี Truckle
แหล่งที่มา

1

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

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

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

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

ในสถานการณ์นี้จะเกิดอะไรขึ้นถ้าคุณรวมการทดสอบวิธีการส่วนตัว เห็นได้ชัดว่ามันไม่มีเหตุผล

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

— bikeman868
แหล่งที่มา

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

— ทอดด์

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

— bikeman868

1

ก่อนที่จะตอบคำถามดังกล่าวคุณต้องตัดสินใจว่าสิ่งใดที่คุณต้องการบรรลุ

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

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

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

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

ภาษาสวิฟต์ช่วยแก้ปัญหาที่คุณไม่ต้องการเปิดเผย A, B, C เป็นวิธีการสาธารณะเพียงเพราะคุณต้องการทดสอบด้วยการให้ฟังก์ชั่นแอตทริบิวต์ "ทดสอบได้" คอมไพเลอร์อนุญาตให้เรียกวิธีการทดสอบส่วนตัวได้จากการทดสอบหน่วย แต่ไม่ใช่จากรหัสที่ไม่ใช่การทดสอบ

— gnasher729
แหล่งที่มา

0

ใช่คุณบ้า ... ชอบสุนัขจิ้งจอก!

มีสองวิธีในการทดสอบวิธีการส่วนตัวซึ่งบางวิธีขึ้นอยู่กับภาษา

การสะท้อนกลับ! กฎถูกทำให้เสียหาย!
ทำให้พวกเขาได้รับการป้องกันสืบทอดและแทนที่
เพื่อน / InternalsVisibleTo เรียน

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

— Ewan
แหล่งที่มา

ฉันไม่ทราบในสายตาของคุณคุณอธิบายว่ามันไม่ใช่ความคิดที่ดี แต่ยังคงตอบคำถามต่อไป

— Liath

ฉันคิดว่าฉันมีฐานทั้งหมดแล้ว :(

— Ewan

3

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

— Robert Harvey

0

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

ฉันเพิ่มinternalaccessor พิเศษ(ร่วมกับการตั้งค่าสถานะInternalsVisibleToชุดทดสอบ), ชื่อที่ชัดเจนDoSomethingForTesting(parameters)เพื่อทดสอบวิธี "ส่วนตัว" เหล่านั้น

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

— Bernhard Hiller
แหล่งที่มา