ฉันจะทดสอบฟังก์ชั่นส่วนตัวหรือชั้นเรียนที่มีวิธีการส่วนตัวเขตข้อมูลหรือชั้นในได้อย่างไร

ฉันจะทดสอบหน่วย (โดยใช้ xUnit) คลาสที่มีวิธีการส่วนตัวภายในเขตข้อมูลหรือคลาสที่ซ้อนกันได้อย่างไร หรือฟังก์ชั่นที่ทำให้เป็นส่วนตัวโดยมีการเชื่อมโยงภายใน ( staticใน C / C ++) หรืออยู่ในเนมสเปซส่วนตัว ( ไม่ระบุชื่อ )?

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

ปรับปรุง:

10 ปีต่อมาบางทีวิธีที่ดีที่สุดในการทดสอบวิธีการส่วนตัวหรือสมาชิกที่ไม่สามารถเข้าถึงได้นั้น@JailbreakมาจากกรอบของManifold

@Jailbreak Foo foo = new Foo();
// Direct, *type-safe* access to *all* foo's members
foo.privateMethod(x, y, z);
foo.privateField = value;

วิธีนี้รหัสของคุณยังคงปลอดภัยและสามารถอ่านได้ ไม่มีการออกแบบที่ประนีประนอมไม่มีวิธีการและการเปิดเผยที่มากเกินไปสำหรับการทดสอบ

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

ภายในเราใช้ผู้ช่วยในการรับ / ตั้งค่าprivateและprivate staticตัวแปรรวมถึงการเรียกใช้privateและprivate staticวิธีการ รูปแบบต่อไปนี้จะช่วยให้คุณสามารถทำสิ่งใดก็ได้ที่เกี่ยวข้องกับวิธีการและฟิลด์ส่วนตัว แน่นอนคุณไม่สามารถเปลี่ยนprivate static finalตัวแปรผ่านการสะท้อนกลับได้

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

และสำหรับเขตข้อมูล:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

หมายเหตุ:
1. TargetClass.getDeclaredMethod(methodName, argClasses)ให้คุณดูprivateวิธีการ getDeclaredFieldสิ่งเดียวกันที่ใช้สำหรับ
2. setAccessible(true)จะต้องเล่นรอบกับเอกชน

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

1. วิธีการส่วนตัวคือรหัสที่ตายแล้ว
2. มีกลิ่นการออกแบบใกล้กับชั้นเรียนที่คุณกำลังทดสอบ
3. วิธีที่คุณพยายามทดสอบไม่ควรเป็นแบบส่วนตัว

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

วิธีการตามปกติของฉันในการจัดการกับปัญหาดังกล่าวคือการแซวคลาสใหม่ที่มีบิตที่น่าสนใจ บ่อยครั้งที่วิธีการนี้และฟิลด์ที่โต้ตอบกับและอาจแยกวิธีอื่นหรือสองวิธีในคลาสใหม่

คลาสใหม่จะเปิดเผยวิธีการเหล่านี้ในลักษณะ 'สาธารณะ' เพื่อให้สามารถเข้าถึงได้สำหรับการทดสอบหน่วย คลาสใหม่และคลาสเก่าตอนนี้ทั้งง่ายกว่าคลาสเดิมซึ่งยอดเยี่ยมสำหรับฉัน (ฉันต้องการให้สิ่งต่าง ๆ เรียบง่ายหรือฉันหลงทาง!)

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

ฉันใช้การไตร่ตรองเพื่อทำสิ่งนี้กับ Java ในอดีตและในความคิดของฉันมันเป็นความผิดพลาดครั้งใหญ่

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

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

จากบทความนี้: การทดสอบวิธีการส่วนตัวกับ JUnit และ SuiteRunner (Bill Venners) คุณโดยทั่วไปมี 4 ตัวเลือก:

1. อย่าทดสอบวิธีการส่วนตัว
2. ให้วิธีการเข้าถึงแพ็คเกจ
3. ใช้คลาสทดสอบที่ซ้อนกัน
4. ใช้การสะท้อนกลับ

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

เพียงสองตัวอย่างที่ฉันต้องการทดสอบวิธีการส่วนตัว:

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

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

ดังนั้นการแลกเปลี่ยนของฉันเกี่ยวข้องกับการทำให้ JUnits เกิดความสับสนมากกว่าจะส่งผลต่อความปลอดภัยและ SDK ของฉัน

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

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

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

ตัวอย่างเช่นถ้าวิธีการที่จะได้รับการทดสอบอยู่ในแล้วโทรทดสอบของคุณควรจะอยู่ในsrc/main/java/mypackage/MyClass.java src/test/java/mypackage/MyClassTest.javaด้วยวิธีนี้คุณจะสามารถเข้าถึงวิธีทดสอบในชั้นทดสอบของคุณ

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

ฉันใช้junitx.util.PrivateAccessor -packageสำหรับ Java liners หนึ่งที่เป็นประโยชน์มากมายสำหรับการเข้าถึงวิธีการส่วนตัวและเขตข้อมูลส่วนตัว

import junitx.util.PrivateAccessor;

PrivateAccessor.setField(myObjectReference, "myCrucialButHardToReachPrivateField", myNewValue);
PrivateAccessor.invoke(myObjectReference, "privateMethodName", java.lang.Class[] parameterTypes, java.lang.Object[] args);

ในSpring Frameworkคุณสามารถทดสอบวิธีส่วนตัวโดยใช้วิธีนี้:

ReflectionTestUtils.invokeMethod()

ตัวอย่างเช่น:

ReflectionTestUtils.invokeMethod(TestClazz, "createTest", "input data");

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

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

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

ข้อดี:

• สามารถทดสอบความละเอียดปลีกย่อย

ข้อเสีย:

• รหัสทดสอบจะต้องอยู่ในไฟล์เดียวกับซอร์สโค้ดซึ่งยากต่อการดูแลรักษา
• เช่นเดียวกันกับไฟล์เอาต์พุต. class จะต้องอยู่ในแพ็คเกจเดียวกันตามที่ได้ประกาศไว้ในซอร์สโค้ด

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

นี่คือตัวอย่างที่ซับซ้อนของวิธีการทำงาน:

// Import statements and package declarations

public class ClassToTest
{
    private int decrement(int toDecrement) {
        toDecrement--;
        return toDecrement;
    }

    // Constructor and the rest of the class

    public static class StaticInnerTest extends TestCase
    {
        public StaticInnerTest(){
            super();
        }

        public void testDecrement(){
            int number = 10;
            ClassToTest toTest= new ClassToTest();
            int decremented = toTest.decrement(number);
            assertEquals(9, decremented);
        }

        public static void main(String[] args) {
            junit.textui.TestRunner.run(StaticInnerTest.class);
        }
    }
}

ชั้นในจะถูกคอมไพล์ClassToTest$StaticInnerTestด้วย

ดูเพิ่มเติมที่: เคล็ดลับ Java 106: คลาสภายในคงที่เพื่อความสนุกสนานและผลกำไร

อย่างที่คนอื่นพูดว่า ... อย่าทดสอบวิธีส่วนตัวโดยตรง นี่คือความคิดบางอย่าง:

1. รักษาทุกวิธีให้เล็กและเน้น (ทดสอบง่ายค้นหาสิ่งที่ผิดได้ง่าย)
2. ใช้เครื่องมือครอบคลุมรหัส ฉันชอบCobertura (โอ้สุขสันต์วันดูเหมือนรุ่นใหม่หมดแล้ว!)

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

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

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

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

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

หากใช้ Spring, ReflectionTestUtilsจะมีเครื่องมือที่มีประโยชน์บางอย่างที่ช่วยเหลือได้โดยง่าย ตัวอย่างเช่นการตั้งค่าการเยาะเย้ยในสมาชิกส่วนตัวโดยไม่ถูกบังคับให้เพิ่ม setter สาธารณะที่ไม่พึงประสงค์:

ReflectionTestUtils.setField(theClass, "theUnsettableField", theMockObject);

หากคุณพยายามทดสอบโค้ดที่มีอยู่ซึ่งคุณลังเลหรือไม่สามารถเปลี่ยนแปลงได้การสะท้อนกลับเป็นทางเลือกที่ดี

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

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

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

ดังนั้นอย่าทดสอบวิธีการส่วนตัว

คำตอบจากหน้าคำถามที่พบบ่อย JUnit.org :

แต่ถ้าคุณต้อง ...

หากคุณกำลังใช้ JDK 1.3 หรือสูงกว่าคุณสามารถใช้การสะท้อนที่จะล้มล้างกลไกการควบคุมการเข้าถึงด้วยความช่วยเหลือของPrivilegedAccessor สำหรับรายละเอียดเกี่ยวกับวิธีการใช้มันอ่านบทความนี้

หากคุณใช้ JDK 1.6 หรือสูงกว่าและใส่คำอธิบายประกอบการทดสอบด้วย @Test คุณสามารถใช้Dp4jเพื่อฉีดการสะท้อนกลับในวิธีการทดสอบของคุณ สำหรับรายละเอียดเกี่ยวกับวิธีการใช้งานให้ดูที่สคริปต์ทดสอบนี้

ป.ล. ฉันเป็นผู้สนับสนุนหลักให้Dp4jถามฉันว่าคุณต้องการความช่วยเหลือหรือไม่ :)

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

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

หากคุณกำลังใช้ JUnit, มีลักษณะที่junit-addons มันมีความสามารถในการละเว้นรูปแบบการรักษาความปลอดภัย Java และเข้าถึงวิธีการและคุณลักษณะส่วนตัว

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

คุณพูดถึงปัญหาประเภทต่างๆ เริ่มจากฟิลด์ส่วนตัวกันก่อน ในกรณีของฟิลด์ส่วนตัวฉันจะเพิ่มตัวสร้างใหม่และฟิลด์ที่แทรกเข้าไปในนั้น แทนสิ่งนี้:

public class ClassToTest {

    private final String first = "first";
    private final List<String> second = new ArrayList<>();
    ...
}

ฉันได้ใช้สิ่งนี้:

public class ClassToTest {

    private final String first;
    private final List<String> second;

    public ClassToTest() {
        this("first", new ArrayList<>());
    }

    public ClassToTest(final String first, final List<String> second) {
        this.first = first;
        this.second = second;
    }
    ...
}

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

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

public ClassToTest() {
    this(...);
}

public ClassToTest(final Callable<T> privateMethodLogic) {
    this.privateMethodLogic = privateMethodLogic;
}

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

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

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

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

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

หากสิ่งทั้งหมดข้างต้นไม่ตรงกับความต้องการของคุณให้ใช้วิธีการไตร่ตรองเพื่อเข้าถึงวิธีการส่วนตัว

ตามที่แนะนำไว้ข้างต้นวิธีที่ดีคือการทดสอบผ่านอินเทอร์เฟซสาธารณะของคุณ

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

นี่คือฟังก์ชั่นทั่วไปของฉันเพื่อทดสอบฟิลด์ส่วนตัว:

protected <F> F getPrivateField(String fieldName, Object obj)
    throws NoSuchFieldException, IllegalAccessException {
    Field field =
        obj.getClass().getDeclaredField(fieldName);

    field.setAccessible(true);
    return (F)field.get(obj);
}

โปรดดูตัวอย่างด้านล่าง;

ควรเพิ่มคำสั่งการนำเข้าต่อไปนี้:

import org.powermock.reflect.Whitebox;

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

Whitebox.invokeMethod(obj, "privateMethod", "param1");

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

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

@UiThreadTest
public void testCompute() {

    // Given
    boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());

    // When
    boundBoxOfMainActivity.boundBox_getButtonMain().performClick();

    // Then
    assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}

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

มันเหมาะสำหรับการทดสอบรหัสดั้งเดิม ใช้อย่างระมัดระวัง ;)

https://github.com/stephanenicolas/boundbox

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

หากพวกเขาใหญ่ขนาดใหญ่พอที่สมาชิกส่วนตัวเหล่านี้แต่ละคนมีขนาดใหญ่ 'ซับซ้อน' - พิจารณาการปรับโครงสร้างสมาชิกเอกชนดังกล่าวออกจากชั้นนี้

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

ฉันเพิ่งมีปัญหานี้และเขียนเครื่องมือเล็ก ๆ น้อย ๆ ที่เรียกว่าPicklockที่หลีกเลี่ยงปัญหาการใช้ Java reflection API อย่างชัดเจนสองตัวอย่าง:

วิธีการโทรเช่นprivate void method(String s)- โดยการสะท้อน Java

Method method = targetClass.getDeclaredMethod("method", String.class);
method.setAccessible(true);
return method.invoke(targetObject, "mystring");

วิธีการโทรเช่นprivate void method(String s)- โดย Picklock

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

การตั้งค่าฟิลด์เช่นprivate BigInteger amount;- โดยการสะท้อน Java

Field field = targetClass.getDeclaredField("amount");
field.setAccessible(true);
field.set(object, BigInteger.valueOf(42));

การตั้งค่าฟิลด์เช่นprivate BigInteger amount;- โดย Picklock

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

PowerMockito สร้างขึ้นเพื่อสิ่งนี้ ใช้การพึ่งพา Maven

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-mockito-release-full</artifactId>
    <version>1.6.4</version>
</dependency>

จากนั้นคุณสามารถทำได้

import org.powermock.reflect.Whitebox;
...
MyClass sut = new MyClass();
SomeType rval = Whitebox.invokeMethod(sut, "myPrivateMethod", params, moreParams);