2012-08-02 73 views
2

虽然重构了一些旧的遗留代码,但我尽可能地应用了单一责任原则,所以我最终得到了许多只有一个目的的类。这很好,但是当我试图为这些新类编写单元测试时出现问题。有些课程很难测试,因为测试很难建立。我需要创建4-5个模拟/存根来编写一个测试用例,如果我想覆盖所有的代码,我需要编写几个测试用例,所以这只是一个痛苦的屁股。SRP让类很难测试

难以建立测试(因为它取决于许多其他类)是否有代码味道?你如何解决这个问题?

+3

我想你将需要发布一些代码......至少有一个示例类。对我来说,你有一个凝聚力问题,而不是一个SRP问题。或者你的SRP太过分了,你的课程变得太专业了。 – 2012-08-02 19:58:55

回答

3

这里是Uncle Bob says about SRP

一个班级应该有一个且只有一个变化的理由。

请注意,它没有说“一个班级只做一件事,只有一件事。”换句话说,对于一个班级来说,如果除了其中一项责任是不变的,或者他们都会一起改变,那么对于一个班级来说,承担多项责任是完全有效的。

在他的书中Agile Patterns, Principles, and Practices,Bob大叔说:

在SRP的背景下,我们定义了一个责任是变革(117)的一个原因。

和:

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

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

0
  • 你不需要所有的代码覆盖,使用常识
  • 随着小班它应该很容易判断不变,所以用断言填充它们,让代码测试本身
  • 分裂您的系统进入层并确定在那里你可以插上模拟刺激把那些声称工作和验证输出