Как издеваться над частными учениками в тестируемом классе с помощью Mockito

Question

У меня есть устаревший класс, в который я добавил несколько методов, и мне нужно создать несколько тестов JUnit, которые тестируют только эти 4 метода.Тестируемый класс имеет конструктор с 1 аргументом, который инициализирует строку.Однако в конструкторе вызывается закрытый метод, который инициализирует несколько закрытых классов и источник данных с использованием файла свойств.Методы, которые я хочу протестировать, не используют ни один из этих классов.

Я новичок в написании тестов JUnit и не уверен, как имитировать этот закрытый метод или если это возможно.
Конструктор классовпроверяется следующее:

public ClassUnderTest(String wlUrl) throws Exception {
try {
    this.url = wlUrl;
    initialize();
} catch (Exception ex) {
    throw ex;
}

} Метод initialize () является закрытым и создает несколько закрытых классов, которые я не использую в методах, которые хочу проверить.

private void initialize() throws Exception {
    try {
        PropertyManager.getInstance();
        logAdapter = LogAdapter.getInstance(PropertyManager.getProperty("LOG_CONFIG_FILE"));    
        log20 = new ServerLogging20();
        ds = (javax.sql.DataSource) ctx.lookup(PropertyManager.getProperty("DATASOURCE"));
        setInitialContext(url);
    } catch (Exception e) {
        log.error("ERROR instantiating PropertyManager & LogAdapter  - " + e.getMessage());
        throw e;
    }
}

Есть ли способ издеваться над этим закрытым методом, чтобы проверить методы, которые я написал?

Answer 1

Mockito не поддерживает мошеннические частные методы.
Вот выдержка из ЧаВо Mockito :

Почему Mockito не дразнит частные методы?

Во-первых, мы не догоняем насчет частных методов.Нам просто не нужны частные методы, потому что с точки зрения тестирования частные методы не существуют.Вот несколько причин, по которым Mockito не высмеивает частные методы:

1. Требуется взлом загрузчиков классов, который никогда не будет пуленепробиваемым, и это меняет API (вы должны использовать пользовательский тестовый прогон, аннотировать класс,так далее.).
2. Обойти это очень легко - просто измените видимость метода с частного на пакетный (или защищенный).
3. Требуется, чтобы команда потратила время на его внедрение и поддержку.И не имеет смысла данный пункт (2) и тот факт, что он уже реализован в другом инструменте (powermock).
4. Наконец-то ... Насмешливые частные методы - это намек на то, что с объектно-ориентированным пониманием что-то не так.В ОО вы хотите, чтобы объекты (или роли) сотрудничали, а не методы.Забудьте про паскаль и процедурный код.Думайте об объектах.

Если вы действительно хотите высмеивать частные методы, посмотрите на PowerMock .