3

在重构一些旧的遗留代码时,我尝试尽可能多地应用单一职责原则,所以我最终得到了许多只有一个目的的类。这很好,但是当我尝试为这些新类编写单元测试时问题就来了。有些类真的很难测试,因为测试很难设置。我需要创建 4-5 个模拟/存根来编写一个测试用例,如果我想覆盖我的所有代码,我需要编写几个测试用例,所以这只是一个麻烦。

难以设置测试(因为它依赖于许多其他类)是代码异味吗?你如何解决这个问题?

4

2 回答 2

3

以下是鲍勃叔叔对 SRP的评价:

一个班级应该有一个,而且只有一个改变的理由。

请注意,它并没有说“一个类只做一件事,而且只做一件事”。换句话说,如果除了其中一个职责之外的所有职责都是不变的,或者如果它们都将一起改变,那么一个类拥有多个职责是完全有效的。

Bob 大叔在他的《敏捷模式、原则和实践》一书中说:

在 SRP 的背景下,我们将责任定义为变更的原因(117)。

和:

另一方面,如果应用程序没有以导致[多个]职责在不同时间发生变化的方式发生变化,则无需将它们分开。事实上,将它们分开会散发出不必要的复杂性。(118)

也就是说,一个有太多合作者的类是一种气味,应该仔细检查。

于 2012-08-02T20:50:16.610 回答
0
  • 您不需要涵盖所有代码,请使用常识
  • 对于小类,应该很容易确定不变量,因此用断言填充它们并让代码自行测试
  • 将您的系统拆分为多个层,并定义您可以在何处插入模拟刺激以使这些断言发挥作用并验证输出
于 2012-08-02T20:34:29.737 回答