Можно ли создать экземпляр класса для тестирования без вызова конструктора?

Вы можете добавить конструктор без параметров в ваш класс и создать сеттер для всех ваших полей.

class ComplexService {
    private Service service1;
    private Service service2;
    private Service service3;
    private Service service4;
    private Service service5;

    public ComplexService(){
      super();
    }
    ...

    public void setService1(Service service1){
      this.service1 = service1;
    }
    //for other fields too
    ...
}

В своем тесте вы называете это как:

myService = new ComplexService()
myService.setService1(service1);
...

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

Вы можете создавать вспомогательные методы как часть вашего тестового кода, например, некоторые фабричные методы с описательными именами, которые создают объект. Например, make_default_ComplexService и более, как вам нужно в ваших тестах. Затем тесты могут использовать эти методы, и если конструктор изменится, во многих случаях вам потребуется обновить только вспомогательные методы, а не все тесты. Этот подход достаточно универсален, чтобы также отделить ваш тест от радикальных изменений, таких как превращение подхода «конструктор с параметрами» в подход «конструктор без аргументов с большим количеством сеттеров».

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

Похоже, вы перепутали несколько терминов и понятий. Позвольте мне помочь вам лучше понять их.

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

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

Мокито нужно сказать, чтобы вызвать реальный метод. Вместо этого было бы предпочтительным фактическое внедрение службы.

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

Пожалуйста, не пытайтесь взломать ваш проверенный класс на основании анализа. Это может привести к неверным результатам тестирования, пустой трате времени и общему разочарованию :) Библиотеки-насмешки, такие как PowerMock и JMockit, предоставляют любые виды хаков, например, те, которые вы пытались реализовать самостоятельно, и в целом они слишком мощные.

С великой силой приходит великая ответственность

Вы можете, но, вероятно, не хотите:

ComplexConstructor partialMock =
    Mockito.mock(ComplexConstructor.class, CALLS_REAL_METHODS);

Этот экземпляр «частичного макета» не будет вызывать свой конструктор или инициализаторы поля, но все вызовы тестируемая система будет вызывать реальное поведение класса. (Технически класс также будет иметь свои переопределенные equals и hashCode для целей Мокито, и класс будет сгенерированным подклассом ComplexConstructor вместо самого ComplexConstructor.)

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

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