Как проверить локальные методы внутреннего класса в java? [дубликат]

вы должны тестировать только открытый интерфейс классов, а не частные члены или частные внутренние классы. Частные члены должны быть деталями реализации, используемыми только общедоступными методами класса (прямо или косвенно). Таким образом, вы можете проверить их косвенно с помощью методов вызывающего абонента. Если вы чувствуете, что у вас недостаточно детализации в этих модульных тестах или что вы не можете почувствовать (некоторые) результаты, которые вас интересуют, это, вероятно, означает проблему с вашим дизайном: класс может быть слишком большой, пытаясь сделать слишком много, поэтому некоторые из его функций могут быть извлечены в отдельный класс, где он может быть непосредственно протестирован.

в текущем примере, если внутренний класс сам содержит много кода, Вы можете просто превратить его в класс верхнего уровня, тогда вы можете напрямую проверить его методы.

(Кстати, Ваш внутренний класс должен быть static если ему не нужно ссылаться на экземпляр заключительного класса.)

вы не можете достичь этих классов извне, поэтому junit не может их проверить. У вас должны быть публичные вещи, чтобы проверить их.

вы должны избегать усложнения кода только потому, что вы

не нравится распространение методы

в вашем случае вы можете проверить методы, если они являются методами внешнего класса или если вам абсолютно нужен внутренний класс, то поместите его вне метода mainAlg (), чтобы он был виден глобально.

public class NewStyle {

    public int mainAlg() {

        Nested n = new Nested();
        int x = n.subAlg01();
        int y = n.subAlg02();

        int z = x * y;
        return z;
    }

    class Nested {

        public int subAlg01() {
            return 3;

        }

        public int subAlg02() {
            return 5;
        }
    }
}

это может быть вызвано с помощью new NewStyle().new Nested().subAlg01();

Hm, я знаю, что такие языки, как Groovy, часто используются для модульного тестирования на Java и могут прозрачно обращаться к частным полям и методам.....но я не уверен в вложенных классах. Я могу понять, почему вы можете захотеть сделать это, но я занимаю ту же позицию, что и с тестированием геттеров и сеттеров, они должны быть протестированы как побочный эффект тестирования ваших публичных методов, и если они не тестируются таким образом, то почему они там для начала?

проблема возникает, когда поведение вашего внутреннего класса оказывается основной частью того, что делает метод: скажем, что у вас есть метод, который должен передать runnable третьему объекту, который оказывается внутренним классом, который действительно не должен быть отдельной сущностью: в этом случае правильное модульное тестирование в значительной степени требует осуществления указанного внутреннего класса, издеваясь над этим третьим объектом и используя захват аргументов для тестирования, он делает то, что должен.

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

но, как было сказано ранее, если ваш внутренний класс никогда не используется внешней стороной, то это просто деталь реализации, и тестирование его отдельно просто не полезно.

на самом деле, вы можете проверить локальный внутренний класс. Но он должен реализовать интерфейс. Таким образом, вы можете создать экземпляр локального класса через отражение и привести его к его интерфейсу. После того, как у вас есть тип интерфейса, вы можете проверить свой код реализации без проблем:

интерфейс:

public interface Algorithm {
    int subAlg01();
    int subAlg02();
}

класс:

public class NewStyle {
    public int mainAlg() {
        class Nested implements Algorithm {

            public int subAlg01() {
                return 3;
            }

            public int subAlg02() {
                return 5;
            }
        }
        Nested n = new Nested();
        int x = n.subAlg01();
        int y = n.subAlg02();
        int z = x * y;
        return z;
    }
}

тест:

public class NewStyleTest {

    @Test
    public void testLocal() throws ClassNotFoundException,
            NoSuchMethodException, SecurityException, InstantiationException,
            IllegalAccessException, IllegalArgumentException,
            InvocationTargetException {
        Class<?> forName = Class.forName("NewStyleNested");
        Constructor<?> declaredConstructor = forName
                .getDeclaredConstructor(NewStyle.class);
        declaredConstructor.setAccessible(true);
        Algorithm algorithm = (Algorithm) declaredConstructor
                .newInstance(new NewStyle());

        assertEquals(algorithm.subAlg01(), 3);
        assertEquals(algorithm.subAlg02(), 5);
    }
}