java - 在java中的单元测试的服务类中注入(inject)不断增长的依赖关系的最佳方法是什么

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 4 年前。

Improve this question

我有一个服务类，它是从发生服务类实例化的 Controller (Jersey Restful api)调用的。这个Service类包含了所有的业务逻辑，所以我们有很多其他的服务，dao注入(inject)到这个类中。为了测试这个类，我们创建了一个构造函数，我们可以在其中注入(inject)这些依赖项并模拟事物。现在真正的问题是，随着该服务类的依赖关系不断增长，构造函数参数也不断增加并且难以维护。有没有其他解决方案/替代方案。

我想过创建 setter 方法并注入(inject)它们，但不确定这是否是理想的做法。

public ManageKitsService(NetworkService velosNetworkService, EmailService emailService, Environment environment, RestClient restClient, Properties properties, ManageKitsDao manageKitsDao, StudyDao studyDao) {
        this.NetworkService = NetworkService;
        this.emailService = emailService;
        this.environment = environment;
        this.restClient = restClient;
        this.properties = properties;
        this.manageKitsDao = manageKitsDao;
        this.studyDao = studyDao;
        .............
       ...............
        ...............
    }

在单元测试中，我们需要模拟所有这些依赖项并传递给构造函数。但是，如果服务类中有某个新的依赖项，那么我们需要将其传递到构造函数中，并更改所有先前的单元测试编译错误。

            private ManageKitsDao mockManageKitsDao;
            private RestClient mockRestClient;

            @BeforeEach
            public void setUp() throws KitException {
               mockManageKitsDao = mock(ManageKitsDao.class);
                mockRestClient = mock(RestClient.class);
               ..............
               ................
             }  

        @Test
        public void itShouldRevokeAssignedKit() {
        when(mockManageKitsDao.getXXXX()).thenReturn(something)
        ...........some other mocking.............
            ManageKitsService manageKitsService = new ManageKitsService(mockNetworkService, mockEmailService, mockEnvironment, mockRestClient, mockProperties, mockManageKitsDao,
                            mockStudyDao);
   assertThatCode(() -> {
    manageKitsService.revokeAssignedKit(123, kitAssignment);
        }).doesNotThrowAnyException();
   }

有没有最好的方法来注入(inject)依赖项来模拟事物并编写单元测试。感谢帮助!

Answer 1

1)错误的正确解决方案:反射

反射(@InjectMocks 和 co)可能会解决你的问题，但它只会鼓励你让你的设计变得更糟。

2)设计返工

您在单元测试中注意到的内容(很难设置要测试的类)并不是最初的问题。这只是被测类中设计问题的结果。
此外，编写具有如此多细粒度操作来模拟的单元测试通常很难实现/读取/维护。
在大多数情况下，如果您碰巧有一个具有许多依赖项(六个或更多)的构造函数，则可能意味着所使用的依赖项对于此类的需求来说太细粒度了。您应该尝试引入一些更高级别的依赖关系来聚合/组合多个依赖关系处理。
最后，这将改进类的设计及其相关的测试。