Як перевірити приватну функцію або клас, який має приватні методи, поля чи внутрішні класи?

Як я можу перевірити (використовуючи 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, і, на мою думку, це була велика помилка.

Строго кажучи, ви не повинні писати одиничні тести, які безпосередньо перевіряють приватні методи. Що ви повинні тестувати, це державний контракт, який у класу є з іншими об'єктами; ніколи не слід безпосередньо перевіряти внутрішні об'єкти. Якщо інший розробник хоче внести невелику внутрішню зміну класу, що не впливає на державний контракт класів, він / вона повинен змінити ваш тест на основі відображення, щоб переконатися, що він працює. Якщо ви робите це неодноразово протягом проекту, одиничні тести потім перестають бути корисним вимірюванням стану коду і починають перешкоджати розвитку та роздратувати команду розробників.

Я рекомендую замість цього використовувати інструмент покриття коду, такий як 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 -пакет для Java. Дуже багато корисних однокласників для доступу до приватних методів та приватних полів.

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

Спробувавши рішення Джема Катікаса, використовуючи роздуми для 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 надає деякі зручні інструменти, які допомагають тут з мінімальними зусиллями. Наприклад, налаштувати макет на приватного члена, не змушуючи його додавати небажаний публічний сетер:

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

Якщо ви намагаєтеся перевірити існуючий код, який ви не хочете або не можете змінити, роздуми - це хороший вибір.

Якщо дизайн класу все ще гнучкий, і у вас є складний приватний метод, який ви хочете перевірити окремо, я пропоную вам витягнути його в окремий клас і протестувати цей клас окремо. Це не повинно змінювати публічний інтерфейс оригінального класу; він може внутрішньо створити екземпляр класу helper і викликати метод helper.

Якщо ви хочете перевірити складні умови помилок, що випливають із допоміжного методу, ви можете піти на крок далі. Витягніть інтерфейс з helper-класу, додайте до початкового класу загальнодоступний getter та сетер, щоб ввести клас helper (використовується через його інтерфейс), а потім введіть макетну версію helper-класу в початковий клас, щоб перевірити, як оригінальний клас відповідає на винятки від помічника. Цей підхід також корисний, якщо ви хочете протестувати оригінальний клас, не перевіряючи також допоміжний клас.

Тестування приватних методів порушує інкапсуляцію вашого класу, оскільки кожен раз, коли ви змінюєте внутрішню реалізацію, ви порушуєте клієнтський код (у цьому випадку тести).

Тому не перевіряйте приватні методи.

Відповідь зі сторінки поширених запитань на JUnit.org :

Але якщо ти повинен ...

Якщо ви використовуєте JDK 1.3 або новішої версії, ви можете використовувати відображення для підриву механізму контролю доступу за допомогою PrivilegedAccessor . Детальніше про те, як ним користуватися, читайте в цій статті .

Якщо ви використовуєте JDK 1.6 або новішу версію, і ви коментуєте свої тести за допомогою @Test, ви можете використовувати Dp4j для введення відображення у ваші методи тестування. Докладніше про те, як його використовувати, див. У цьому тестовому сценарії .

PS Я основний довідник Dp4j , запитайте , чи потрібна вам допомога. :)

Якщо ви хочете перевірити приватні методи застарілої програми, де ви не можете змінити код, одним із варіантів для Java є jMockit , який дозволить вам створювати макети до об'єкта, навіть коли вони приватні для класу.

Я, як правило, не перевіряю приватні методи. Там лежить божевілля. Особисто я вважаю, що ви повинні перевірити лише свої відкриті інтерфейси (це включає захищені та внутрішні методи).

Якщо ви використовуєте 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;
    }
    ...
}

Це не буде проблемою навіть зі старим кодом. Старий код буде використовувати порожній конструктор, і якщо ви запитаєте мене, код, який переробляється, буде виглядати чистіше, і ви зможете ввести необхідні значення в тест без роздумів.

Тепер про приватні методи. З мого особистого досвіду, коли вам доведеться заглушити приватний метод тестування, тоді цей метод не має нічого спільного в цьому класі. Загальним шаблоном у такому випадку буде загортання його в інтерфейс, наприклад, Callableа потім ви передаєте цей інтерфейс також у конструктор (з цим численним трюком конструктора):

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

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

Переважно все, що я написав, виглядає так, що це схема введення залежності. В моєму особистому досвіді це дуже корисно під час тестування, і я думаю, що такий код чистіший і його буде легше підтримувати. Я б сказав те саме про вкладені класи. Якщо вкладений клас містить важку логіку, було б краще, якби ви перемістили його як приватний клас пакету та ввели його до потрібного класу.

Існує також кілька інших моделей дизайну, які я використовував під час рефакторингу та збереження застарілого коду, але все залежить від випадків перевірки вашого коду. Використання рефлексії здебільшого не є проблемою, але коли у вас є корпоративна програма, яка проходить тестування і запускаються тести перед кожним розгортанням, все стає дуже повільним (це просто дратує, і мені подібні речі не подобаються).

Існує також ін'єкція сетера, але я не рекомендував би його використовувати. Я б краще дотримуватися конструктора і ініціалізувати все, коли це дійсно необхідно, залишаючи можливість вводити необхідні залежності.

До приватного методу можна отримати доступ лише в одному класі. Тому немає можливості перевірити "приватний" метод цільового класу з будь-якого тестового класу. Виходом є те, що ви можете виконати тестування блоку вручну або змінити свій метод з "приватного" на "захищений".

І тоді захищений метод може бути доступний лише в тому ж пакеті, де визначено клас. Отже, тестування захищеного методу цільового класу означає, що нам потрібно визначити ваш тестовий клас у тому ж пакеті, що і цільовий клас.

Якщо все вищесказане не відповідає вашим вимогам, використовуйте спосіб відображення для доступу до приватного методу.

Як багато з них було запропоновано, хороший спосіб - протестувати їх через свої загальнодоступні інтерфейси.

Якщо ви це зробите, корисно використовувати інструмент покриття коду (наприклад, Емма), щоб перевірити, чи справді ваші приватні методи виконуються з ваших тестів.

Ось моя загальна функція для тестування приватних полів:

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 , який дозволяє уникнути проблем явного використання API відбиття Java, два приклади:

Методи виклику, наприклад 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)- Піклок

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