Junit тест для частного метода

Question

Я прочитал этот вопрос: How do I test a class that has private methods, fields or inner classes? и кажется, что у меня может быть запах кода, но мой код очень прост для рефакторинга. что не так в дизайне, который я создал. Я создал класс делегата для обработки некоторых действий он три метода execute(Action);PopulateActionHandlers() и executeActionhandlers(); Моего класса, как показано ниже:

public class DelegateHandler{ 
    Map<Integer,ActionHandlers> handlerMaps; 

    public execute(Action action){ 
     populateActionHandlers(action); 
     executeActionHandlers(); 

    }//end of execute 

    //This method can create and populate more than one handlers in handlerMap 
    private populateActionHandlers(action){ 
     handlerMap = new LinkedHashMap<ActionHandlers>(); 
     if (action.isMultimode()){ 
      handlerMap.add(1,new handler(action.getabc())); 
      handlerMap.add(2,new handler(action.getabc()-1)); 
     }else{ 
      handlerMap.add(1,new handler(action)); 
     } 

    }//end of populateActionHandlers 

    //This method can execute more than one handlers in handlerMap 
    private executeActionHandlers(){ 
     for(ActionHandler actionHandler : handlerMap.values){ 
      actionHandler.executeAction(); 
     } 

    }//end of executeActionHandlers 
} 

Теперь я хочу проверить populateActionHandlers() метод с JUnit, который я сделал как частный, есть нет необходимости выставлять его вне этого класса. Если я проведу метод execute(), он проверит оба метода: populateActionHandlers() и executeActionHandlers(), которые одновременно тестируют два устройства, я хочу их протестировать отдельно. Дизайн (я думаю) кажется мне в порядке и не позволяет никаких проблем, но тогда я либо изменил бы доступ к методу (и только ради тестирования это не оправдывает это, на мой взгляд, правильно?) Или использовать рефлексия (это хорошая идея, она как-то не так-то чувствует, обычно ли люди используют рефлексию для тестирования юнита?). Так что единственное, что нельзя исключить, - это запах кода. Но может быть, мой код синус не помогает мне. Поэтому я хотел бы понять, могу ли я улучшить этот код.

Answer 1

Рекомендация не тестировать частные методы не должна препятствовать тому, чтобы вы делали странный дизайн, оставив закрытый метод, но должны применять для проверки только методы, которые имеют четкую семантику.

Частные методы обычно являются техническими помощниками. Их семантика может измениться, если базовые структуры данных изменятся, их даже можно оптимизировать, если вызывающие общедоступные методы используют другой алгоритм для достижения тех же целей.

Я хотел бы переписать программка в следующим образом:

... 
public execute(Action action){ 
    Map<Integer,ActionHandlers> handlerMap = populateActionHandlers(action); 
    executeActionHandlers(handlerMap); 
} 
... 

Сохранение результатов одной функции в частном поле только для извлечения его из этого поля в другой функции не THREADSAFE и труднее поддерживать.

Однако этот рефакторинг завершит работу над всеми (пока не написанными) тестами, которые проверили частный метод вашего примера, поскольку интерфейс изменен. Если вы только протестировали открытый метод, все тесты будут действительны после этого рефакторинга.

Я знаю несколько случаев, когда тестирование частных методов в порядке. Хотя тестирование частных методов часто можно избежать, я считаю, что проверка частного состояния иногда является лучшей альтернативой, чем проверка состояния публичных объектов. Такие проверки могут быть не такими надежными (причины, как указано выше), но общественное государство часто является неполным и трудно утверждать. В обоих случаях я использую фреймворк picklock, который позволяет получить доступ к приватным методам и полям удобным способом.