Làm cách nào để kiểm tra một hàm riêng hoặc một lớp có các phương thức riêng, các trường hoặc các lớp bên trong?

Làm cách nào để kiểm tra đơn vị (sử dụng xUnit) một lớp có các phương thức riêng tư nội bộ, các trường hoặc các lớp lồng nhau? Hoặc một chức năng được đặt ở chế độ riêng tư bằng cách có liên kết nội bộ ( statictrong C / C ++) hoặc trong một không gian tên riêng ( ẩn danh )?

Có vẻ không tốt khi thay đổi công cụ sửa đổi truy cập cho một phương thức hoặc chức năng chỉ để có thể chạy thử nghiệm.

Cập nhật:

Khoảng 10 năm sau đó có lẽ là cách tốt nhất để thử nghiệm một phương pháp tư nhân, hoặc bất kỳ thành viên không thể tiếp cận, là thông qua @Jailbreaktừ Manifold khuôn khổ.

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

Bằng cách này, mã của bạn vẫn an toàn và dễ đọc. Không thỏa hiệp thiết kế, không có phương pháp và trường quá mức cho mục đích thử nghiệm.

Nếu bạn có một phần của ứng dụng Java cũ và bạn không được phép thay đổi mức độ hiển thị của các phương thức của mình, cách tốt nhất để kiểm tra các phương thức riêng là sử dụng sự phản chiếu .

Trong nội bộ, chúng tôi đang sử dụng các trình trợ giúp để nhận / đặt privatevà private staticcác biến cũng như gọi privatevà private staticphương thức. Các mẫu sau sẽ cho phép bạn thực hiện khá nhiều thứ liên quan đến các phương thức và trường riêng. Tất nhiên, bạn không thể thay đổi private static finalcác biến thông qua sự phản chiếu.

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

Và cho các lĩnh vực:

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

Ghi chú:
1. TargetClass.getDeclaredMethod(methodName, argClasses)cho phép bạn xem xét privatecác phương pháp. Điều tương tự áp dụng cho getDeclaredField.
2. Bắt setAccessible(true)buộc phải chơi xung quanh với tư nhân.

Cách tốt nhất để kiểm tra một phương thức riêng là thông qua một phương thức công khai khác. Nếu điều này không thể được thực hiện, thì một trong những điều kiện sau là đúng:

1. Phương thức riêng là mã chết
2. Có một mùi thiết kế gần lớp mà bạn đang thử nghiệm
3. Phương pháp mà bạn đang cố kiểm tra không nên riêng tư

Khi tôi có các phương thức riêng trong một lớp đủ phức tạp đến mức tôi cảm thấy cần phải kiểm tra trực tiếp các phương thức riêng đó, đó là mùi mã: lớp của tôi quá phức tạp.

Cách tiếp cận thông thường của tôi để giải quyết các vấn đề như vậy là trêu chọc một lớp mới có chứa các bit thú vị. Thông thường, phương thức này và các trường mà nó tương tác với, và có thể một hoặc hai phương thức khác có thể được trích xuất sang một lớp mới.

Lớp mới hiển thị các phương thức này là 'công khai', vì vậy chúng có thể truy cập để kiểm tra đơn vị. Các lớp mới và cũ bây giờ đều đơn giản hơn lớp gốc, rất phù hợp với tôi (tôi cần giữ mọi thứ đơn giản, hoặc tôi bị lạc!).

Lưu ý rằng tôi không gợi ý rằng mọi người tạo lớp mà không sử dụng bộ não của họ! Vấn đề ở đây là sử dụng các lực lượng kiểm thử đơn vị để giúp bạn tìm các lớp mới tốt.

Tôi đã sử dụng sự phản chiếu để làm điều này cho Java trong quá khứ và theo tôi đó là một sai lầm lớn.

Nói đúng ra, bạn không nên viết bài kiểm tra đơn vị trực tiếp kiểm tra các phương pháp riêng tư. Những gì bạn nên kiểm tra là hợp đồng công khai mà lớp có với các đối tượng khác; bạn không bao giờ nên trực tiếp kiểm tra nội bộ của một đối tượng. Nếu một nhà phát triển khác muốn thực hiện một thay đổi nhỏ đối với lớp, điều này không ảnh hưởng đến hợp đồng công khai của lớp, thì anh ta / cô ta phải sửa đổi thử nghiệm dựa trên phản ánh của bạn để đảm bảo rằng nó hoạt động. Nếu bạn làm điều này nhiều lần trong suốt một dự án, thì các bài kiểm tra đơn vị sẽ ngừng là một phép đo hữu ích về sức khỏe mã và bắt đầu trở thành một trở ngại cho sự phát triển và gây khó chịu cho nhóm phát triển.

Thay vào đó, những gì tôi khuyên bạn nên làm là sử dụng một công cụ bao phủ mã như Cobertura, để đảm bảo rằng các bài kiểm tra đơn vị bạn viết cung cấp mức độ bao phủ tốt của mã trong các phương thức riêng tư. Bằng cách đó, bạn gián tiếp kiểm tra những gì các phương thức riêng đang làm và duy trì mức độ nhanh nhẹn cao hơn.

Từ bài viết này: Thử nghiệm các phương thức riêng tư với JUnit và SuiteRunner (Bill Venners), về cơ bản bạn có 4 tùy chọn:

1. Đừng thử phương pháp riêng tư.
2. Cung cấp cho các phương thức truy cập gói.
3. Sử dụng một lớp kiểm tra lồng nhau.
4. Sử dụng phản xạ.

Nói chung, một bài kiểm tra đơn vị được dự định để thực hiện giao diện chung của một lớp hoặc đơn vị. Do đó, các phương thức riêng là chi tiết triển khai mà bạn không muốn kiểm tra một cách rõ ràng.

Chỉ cần hai ví dụ về nơi tôi muốn thử nghiệm một phương thức riêng tư:

1. Thói quen giải mã - Tôi sẽ không muốn mọi người nhìn thấy chúng để xem chỉ vì mục đích thử nghiệm, bất kỳ ai khác cũng có thể sử dụng chúng để giải mã. Nhưng chúng là bản chất của mã, phức tạp và cần phải luôn hoạt động (ngoại lệ rõ ràng là sự phản chiếu có thể được sử dụng để xem ngay cả các phương thức riêng tư trong hầu hết các trường hợp, khiSecurityManager không được cấu hình để ngăn chặn điều này).
2. Tạo SDK cho tiêu dùng cộng đồng. Ở đây công chúng mang một ý nghĩa hoàn toàn khác, vì đây là mã mà cả thế giới có thể thấy (không chỉ nội bộ trong ứng dụng của tôi). Tôi đặt mã vào các phương thức riêng tư nếu tôi không muốn người dùng SDK thấy nó - Tôi không thấy đây là mùi mã, chỉ đơn thuần là cách lập trình SDK hoạt động. Nhưng tất nhiên tôi vẫn cần thử nghiệm các phương thức riêng tư của mình và chúng là nơi chức năng của SDK của tôi thực sự sống.

Tôi hiểu ý tưởng chỉ thử nghiệm "hợp đồng". Nhưng tôi không thấy người ta có thể ủng hộ việc thực sự không kiểm tra mã - số dặm của bạn có thể thay đổi.

Vì vậy, sự đánh đổi của tôi liên quan đến việc làm phức tạp JUnits bằng sự phản chiếu, thay vì ảnh hưởng đến bảo mật & SDK của tôi.

Các phương thức riêng được gọi bằng một phương thức công khai, vì vậy các đầu vào cho các phương thức công khai của bạn cũng nên kiểm tra các phương thức riêng được gọi bằng các phương thức công khai đó. Khi một phương thức công khai thất bại, thì đó có thể là một thất bại trong phương thức riêng tư.

Một cách tiếp cận khác mà tôi đã sử dụng là thay đổi một phương thức riêng tư để đóng gói riêng tư hoặc được bảo vệ, sau đó bổ sung nó bằng @VisibleForTesting chú thích của thư viện Google Guava.

Điều này sẽ nói với bất kỳ ai sử dụng phương pháp này để thận trọng và không truy cập trực tiếp ngay cả trong một gói. Ngoài ra, một lớp kiểm tra không cần phải ở cùng một gói vật lý , nhưng trong cùng một gói theo thử nghiệm thư mục .

Ví dụ: nếu một phương thức được kiểm tra src/main/java/mypackage/MyClass.javathì cuộc gọi thử nghiệm của bạn sẽ được đặt src/test/java/mypackage/MyClassTest.java. Bằng cách đó, bạn có quyền truy cập vào phương thức kiểm tra trong lớp kiểm tra của mình.

Để kiểm tra mã kế thừa với các lớp lớn và kỳ quặc, thường rất hữu ích khi có thể kiểm tra một phương thức riêng tư (hoặc công khai) mà tôi đang viết ngay bây giờ .

Tôi sử dụng gói Junitx.util.PrivateAccessor cho Java. Rất nhiều lớp lót hữu ích để truy cập các phương thức riêng tư và các trường riêng.

import junitx.util.PrivateAccessor;

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

Trong Spring Framework, bạn có thể kiểm tra các phương thức riêng tư bằng phương thức này:

ReflectionTestUtils.invokeMethod()

Ví dụ:

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

Đã thử giải pháp của Cem Catikkas bằng phản xạ cho Java, tôi phải nói rằng đây là một giải pháp tao nhã hơn tôi đã mô tả ở đây. Tuy nhiên, nếu bạn đang tìm kiếm một giải pháp thay thế cho việc sử dụng sự phản chiếu và có quyền truy cập vào nguồn bạn đang kiểm tra, thì đây vẫn sẽ là một lựa chọn.

Có khả năng trong việc thử nghiệm các phương thức riêng của một lớp, đặc biệt là với sự phát triển dựa trên thử nghiệm , nơi bạn muốn thiết kế các thử nghiệm nhỏ trước khi bạn viết bất kỳ mã nào.

Tạo một thử nghiệm với quyền truy cập vào các thành viên và phương thức riêng tư có thể kiểm tra các vùng mã khó nhắm mục tiêu cụ thể chỉ với quyền truy cập vào các phương thức công khai. Nếu một phương thức công khai có một số bước liên quan, nó có thể bao gồm một số phương thức riêng tư, sau đó có thể được kiểm tra riêng lẻ.

Ưu điểm:

• Có thể kiểm tra độ chi tiết mịn hơn

Nhược điểm:

• Mã kiểm tra phải nằm trong cùng một tệp với mã nguồn, có thể khó duy trì hơn
• Tương tự với các tệp đầu ra. Class, chúng phải nằm trong cùng một gói như được khai báo trong mã nguồn

Tuy nhiên, nếu thử nghiệm liên tục yêu cầu phương pháp này, nó có thể là một tín hiệu cho thấy các phương thức riêng nên được trích xuất, có thể được thử nghiệm theo cách truyền thống, công khai.

Đây là một ví dụ phức tạp về cách thức này sẽ hoạt động:

// 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);
        }
    }
}

Lớp bên trong sẽ được biên dịch thành ClassToTest$StaticInnerTest.

Xem thêm: Mẹo Java 106: Các lớp bên trong tĩnh để giải trí và kiếm lợi nhuận

Như những người khác đã nói ... không thử trực tiếp các phương pháp riêng tư. Dưới đây là một vài suy nghĩ:

1. Giữ tất cả các phương pháp nhỏ và tập trung (dễ kiểm tra, dễ tìm thấy những gì sai)
2. Sử dụng các công cụ bảo hiểm mã. Tôi thích Cobertura (ôi ngày hạnh phúc, có vẻ như đã có phiên bản mới!)

Chạy phạm vi bảo hiểm mã trên các bài kiểm tra đơn vị. Nếu bạn thấy rằng các phương thức không được kiểm tra đầy đủ, hãy thêm vào các bài kiểm tra để có được phạm vi bảo hiểm. Nhằm mục đích bảo hiểm mã 100%, nhưng nhận ra rằng bạn có thể sẽ không nhận được nó.

Phương pháp riêng tư được tiêu thụ bởi những người công cộng. Nếu không, chúng là mã chết. Đó là lý do tại sao bạn thử nghiệm phương thức công khai, khẳng định kết quả mong đợi của phương thức công khai và do đó, phương pháp riêng mà nó sử dụng.

Kiểm tra các phương thức riêng tư nên được kiểm tra bằng cách gỡ lỗi trước khi chạy thử nghiệm đơn vị của bạn trên các phương thức công khai.

Chúng cũng có thể được gỡ lỗi bằng cách sử dụng phát triển dựa trên kiểm tra, gỡ lỗi kiểm tra đơn vị của bạn cho đến khi tất cả các xác nhận của bạn được đáp ứng.

Cá nhân tôi tin rằng tốt hơn là tạo các lớp bằng TDD; tạo sơ khai phương thức công khai, sau đó tạo các thử nghiệm đơn vị với tất cả các xác nhận được xác định trước, do đó, kết quả mong đợi của phương thức được xác định trước khi bạn mã hóa nó. Bằng cách này, bạn không đi sai đường dẫn đến việc xác nhận kiểm tra đơn vị phù hợp với kết quả. Lớp học của bạn sau đó mạnh mẽ và đáp ứng các yêu cầu khi tất cả các bài kiểm tra đơn vị của bạn vượt qua.

Nếu sử dụng Spring, ReflectionTestUtils cung cấp một số công cụ hữu ích giúp đỡ ở đây với nỗ lực tối thiểu. Ví dụ: để thiết lập một bản giả trên một thành viên riêng mà không bị buộc phải thêm một trình thiết lập công khai không mong muốn:

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

Nếu bạn đang cố kiểm tra mã hiện tại mà bạn miễn cưỡng hoặc không thể thay đổi, thì sự phản chiếu là một lựa chọn tốt.

Nếu thiết kế của lớp vẫn linh hoạt và bạn đã có một phương thức riêng phức tạp mà bạn muốn kiểm tra riêng, tôi khuyên bạn nên rút nó ra thành một lớp riêng và kiểm tra riêng lớp đó. Điều này không phải thay đổi giao diện chung của lớp gốc; bên trong nó có thể tạo một thể hiện của lớp trình trợ giúp và gọi phương thức của trình trợ giúp.

Nếu bạn muốn kiểm tra các điều kiện lỗi khó khăn đến từ phương thức trợ giúp, bạn có thể tiến thêm một bước. Trích xuất một giao diện từ lớp trình trợ giúp, thêm một getter công khai và setter vào lớp gốc để tiêm lớp trình trợ giúp (được sử dụng thông qua giao diện của nó), sau đó đưa một phiên bản giả của lớp trình trợ giúp vào lớp ban đầu để kiểm tra cách lớp gốc đáp ứng với các ngoại lệ từ người trợ giúp. Cách tiếp cận này cũng hữu ích nếu bạn muốn kiểm tra lớp gốc mà không kiểm tra lớp người trợ giúp.

Kiểm tra các phương thức riêng phá vỡ sự đóng gói của lớp của bạn bởi vì mỗi khi bạn thay đổi triển khai nội bộ, bạn sẽ phá vỡ mã máy khách (trong trường hợp này là các kiểm tra).

Vì vậy, đừng thử nghiệm các phương pháp riêng tư.

Câu trả lời từ trang Câu hỏi thường gặp của JUnit.org :

Nhưng nếu bạn phải ...

Nếu bạn đang sử dụng JDK 1.3 trở lên, bạn có thể sử dụng sự phản chiếu để lật đổ cơ chế kiểm soát truy cập với sự trợ giúp của Đặc quyền . Để biết chi tiết về cách sử dụng nó, hãy đọc bài viết này .

Nếu bạn đang sử dụng JDK 1.6 trở lên và bạn chú thích các thử nghiệm của mình với @Test, bạn có thể sử dụng Dp4j để thực hiện phản xạ trong các phương thức thử nghiệm của mình. Để biết chi tiết về cách sử dụng nó, xem tập lệnh thử nghiệm này .

PS Tôi là người đóng góp chính cho Dp4j , hãy hỏi tôi nếu bạn cần giúp đỡ. :)

Nếu bạn muốn kiểm tra các phương thức riêng tư của một ứng dụng cũ, nơi bạn không thể thay đổi mã, một tùy chọn cho Java là jMockit , cho phép bạn tạo giả cho một đối tượng ngay cả khi chúng riêng tư với lớp.

Tôi có xu hướng không thử nghiệm các phương pháp riêng tư. Có sự điên rồ. Cá nhân, tôi tin rằng bạn chỉ nên kiểm tra các giao diện được hiển thị công khai của mình (và bao gồm các phương thức được bảo vệ và nội bộ).

Nếu bạn đang sử dụng JUnit, hãy xem Junit-addons . Nó có khả năng bỏ qua mô hình bảo mật Java và truy cập các phương thức và thuộc tính riêng tư.

Tôi sẽ đề nghị bạn tái cấu trúc mã của bạn một chút. Khi bạn phải bắt đầu suy nghĩ về việc sử dụng sự phản chiếu hoặc các loại công cụ khác, vì chỉ kiểm tra mã của bạn, có gì đó không ổn với mã của bạn.

Bạn đã đề cập đến các loại vấn đề khác nhau. Hãy bắt đầu với các lĩnh vực tư nhân. Trong trường hợp các trường riêng tư, tôi đã thêm một hàm tạo mới và các trường được thêm vào đó. Thay vì điều này:

public class ClassToTest {

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

Tôi đã sử dụng cái này:

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;
    }
    ...
}

Đây sẽ không phải là một vấn đề ngay cả với một số mã kế thừa. Mã cũ sẽ sử dụng một hàm tạo trống và nếu bạn hỏi tôi, mã được cấu trúc lại sẽ trông sạch hơn và bạn sẽ có thể đưa các giá trị cần thiết vào thử nghiệm mà không bị phản xạ.

Bây giờ về phương pháp riêng tư. Theo kinh nghiệm cá nhân của tôi khi bạn phải bỏ một phương thức riêng để thử nghiệm, thì phương thức đó không có gì để làm trong lớp đó. Trong trường hợp đó, một mẫu chung sẽ là bọc nó trong một giao diện, giống như Callablevà sau đó bạn chuyển qua giao diện đó trong hàm tạo (với thủ thuật nhiều hàm tạo đó):

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

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

Chủ yếu là tất cả những gì tôi đã viết trông giống như một mô hình tiêm phụ thuộc. Theo kinh nghiệm cá nhân của tôi, nó thực sự hữu ích trong khi thử nghiệm và tôi nghĩ rằng loại mã này sạch hơn và sẽ dễ bảo trì hơn. Tôi cũng nói như vậy về các lớp lồng nhau. Nếu một lớp lồng nhau chứa logic nặng thì sẽ tốt hơn nếu bạn chuyển nó thành một lớp riêng và đã đưa nó vào một lớp cần nó.

Ngoài ra còn có một số mẫu thiết kế khác mà tôi đã sử dụng trong khi tái cấu trúc và duy trì mã kế thừa, nhưng tất cả phụ thuộc vào các trường hợp mã của bạn để kiểm tra. Sử dụng sự phản chiếu hầu như không phải là một vấn đề, nhưng khi bạn có một ứng dụng doanh nghiệp được kiểm tra nhiều và các thử nghiệm được chạy trước khi mọi triển khai thì mọi thứ trở nên rất chậm (điều đó thật khó chịu và tôi không thích kiểu đó).

Ngoài ra còn có tiêm setter, nhưng tôi không khuyến khích sử dụng. Tôi tốt hơn nên gắn bó với một nhà xây dựng và khởi tạo mọi thứ khi thực sự cần thiết, để lại khả năng tiêm các phụ thuộc cần thiết.

Một phương thức riêng tư chỉ được truy cập trong cùng một lớp. Vì vậy, không có cách nào để kiểm tra một phương thức riêng tư của Trực tuyến của một lớp mục tiêu từ bất kỳ lớp kiểm tra nào. Một lối thoát là bạn có thể thực hiện kiểm tra đơn vị theo cách thủ công hoặc có thể thay đổi phương thức của mình từ chế độ riêng tư của người dùng thành người được bảo vệ.

Và sau đó, một phương thức được bảo vệ chỉ có thể được truy cập trong cùng một gói nơi lớp được định nghĩa. Vì vậy, kiểm tra một phương thức được bảo vệ của lớp mục tiêu có nghĩa là chúng ta cần xác định lớp kiểm tra của bạn trong cùng gói với lớp mục tiêu.

Nếu tất cả các cách trên không phù hợp với yêu cầu của bạn, hãy sử dụng cách phản ánh để truy cập phương thức riêng tư.

Như nhiều người ở trên đã đề xuất, một cách tốt là kiểm tra chúng thông qua các giao diện công cộng của bạn.

Nếu bạn làm điều này, nên sử dụng một công cụ bao phủ mã (như Emma) để xem liệu các phương thức riêng tư của bạn có thực sự được thực hiện từ các thử nghiệm của bạn hay không.

Đây là chức năng chung của tôi để kiểm tra các trường riêng:

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);
}

Xin vui lòng xem dưới đây cho một ví dụ;

Cần thêm câu lệnh nhập sau:

import org.powermock.reflect.Whitebox;

Bây giờ bạn có thể trực tiếp truyền đối tượng có phương thức riêng, tên phương thức được gọi và các tham số bổ sung như dưới đây.

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

Hôm nay, tôi đã đẩy một thư viện Java để giúp kiểm tra các phương thức và trường riêng. Nó đã được thiết kế dành cho Android, nhưng nó thực sự có thể được sử dụng cho bất kỳ dự án Java nào.

Nếu bạn có một số mã với các phương thức riêng tư hoặc các trường hoặc hàm tạo, bạn có thể sử dụng BoundBox . Nó làm chính xác những gì bạn đang tìm kiếm. Dưới đây là một ví dụ về thử nghiệm truy cập hai trường riêng của một hoạt động Android để kiểm tra nó:

@UiThreadTest
public void testCompute() {

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

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

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

BoundBox giúp dễ dàng kiểm tra các trường, phương thức và hàm tạo riêng tư / được bảo vệ. Bạn thậm chí có thể truy cập những thứ bị ẩn bởi thừa kế. Thật vậy, BoundBox phá vỡ đóng gói. Nó sẽ cung cấp cho bạn quyền truy cập vào tất cả những điều đó thông qua sự phản ánh, NHƯNG mọi thứ đều được kiểm tra tại thời điểm biên dịch.

Đó là lý tưởng để thử nghiệm một số mã kế thừa. Sử dụng cẩn thận. ;)

https://github.com/stephanenicolas/boundbox

Đầu tiên, tôi sẽ ném câu hỏi này ra: Tại sao các thành viên tư nhân của bạn cần thử nghiệm biệt lập? Có phải chúng phức tạp, cung cấp các hành vi phức tạp như vậy để yêu cầu thử nghiệm ngoài bề mặt công cộng? Đó là thử nghiệm đơn vị, không phải thử nghiệm 'dòng mã'. Đừng đổ mồ hôi những thứ nhỏ nhặt.

Nếu chúng đủ lớn, đủ lớn để các thành viên tư nhân này có độ phức tạp lớn của một "đơn vị" - hãy xem xét tái cấu trúc các thành viên tư nhân đó ra khỏi lớp này.

Nếu tái cấu trúc là không phù hợp hoặc không khả thi, bạn có thể sử dụng mẫu chiến lược để thay thế quyền truy cập vào các hàm thành viên / lớp thành viên riêng này khi được kiểm tra đơn vị không? Trong thử nghiệm đơn vị, chiến lược sẽ cung cấp xác nhận bổ sung, nhưng trong các bản dựng phát hành, nó sẽ đơn giản vượt qua.

Gần đây tôi có vấn đề này và đã viết một công cụ nhỏ, được gọi là Picklock , để tránh các vấn đề rõ ràng khi sử dụng API phản chiếu Java, hai ví dụ:

Các phương thức gọi, ví dụ private void method(String s)- bằng phản xạ Java

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

Phương thức gọi, ví dụ private void method(String s)- bởi Picklock

interface Accessible {
  void method(String s);
}

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

Đặt các trường, ví dụ private BigInteger amount;- bằng phản chiếu Java

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

Cài đặt các trường, ví dụ private BigInteger amount;- bởi Picklock

interface Accessible {
  void setAmount(BigInteger amount);
}

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

PowerMockito được tạo ra cho việc này. Sử dụng phụ thuộc maven

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

Sau đó bạn có thể làm

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