在重构一些旧的遗留代码时,我尝试尽可能多地应用单一职责原则,所以我最终得到了许多只有一个目的的类。这很好,但是当我尝试为这些新类编写单元测试时问题就来了。有些类真的很难测试,因为测试很难设置。我需要创建 4-5 个模拟/存根来编写一个测试用例,如果我想覆盖我的所有代码,我需要编写几个测试用例,所以这只是一个麻烦。
难以设置测试(因为它依赖于许多其他类)是代码异味吗?你如何解决这个问题?
在重构一些旧的遗留代码时,我尝试尽可能多地应用单一职责原则,所以我最终得到了许多只有一个目的的类。这很好,但是当我尝试为这些新类编写单元测试时问题就来了。有些类真的很难测试,因为测试很难设置。我需要创建 4-5 个模拟/存根来编写一个测试用例,如果我想覆盖我的所有代码,我需要编写几个测试用例,所以这只是一个麻烦。
难以设置测试(因为它依赖于许多其他类)是代码异味吗?你如何解决这个问题?
以下是鲍勃叔叔对 SRP的评价:
一个班级应该有一个,而且只有一个改变的理由。
请注意,它并没有说“一个类只做一件事,而且只做一件事”。换句话说,如果除了其中一个职责之外的所有职责都是不变的,或者如果它们都将一起改变,那么一个类拥有多个职责是完全有效的。
Bob 大叔在他的《敏捷模式、原则和实践》一书中说:
在 SRP 的背景下,我们将责任定义为变更的原因(117)。
和:
另一方面,如果应用程序没有以导致[多个]职责在不同时间发生变化的方式发生变化,则无需将它们分开。事实上,将它们分开会散发出不必要的复杂性。(118)
也就是说,一个有太多合作者的类是一种气味,应该仔细检查。