如何避免使用Mocks重复逻辑

我有以下挑战,我没有找到一个好的答案.我正在使用Mocking框架(在本例中为JMock),以允许单元测试与数据库代码隔离.我正在模拟对涉及数据库逻辑的类的访问,并使用DBUnit单独测试数据库类.

我遇到的问题是我注意到逻辑在概念上在多个地方重复的模式.例如,我需要检测数据库中的值不存在,因此在这种情况下我可能会从方法返回null.所以我有一个数据库访问类来进行数据库交互,并适当地返回null.然后我有业务逻辑类,它从模拟接收null,然后测试如果值为null则适当地执行.

现在如果将来行为需要改变并且返回null不再合适,比如因为状态变得更加复杂,那么我将需要返回一个报告值不存在的对象以及一些其他事实来自数据库.

现在,如果我在这种情况下将数据库类的行为更改为不再返回null,那么业务逻辑类仍然会起作用,并且该错误只会在QA中捕获,除非有人记住耦合,或者正确地遵循了方法的用法.

我失去了一些东西,我必须有一个更好的方法来避免这种概念上的重复,或者至少让它受到测试,这样如果它发生变化,变化没有传播的事实就不能通过单元测试.

有什么建议？

更新:

让我试着澄清一下我的问题.我正在考虑代码何时随着时间的推移而发展,如何确保集成不会在通过模拟和模拟代表的类的实际实现测试的类之间中断.

例如,我只有一个案例,我有一个最初创建的方法,并没有期望空值,所以这不是对真实对象的测试.然后,在某些情况下,类的用户(通过模拟测试)被增强以传入null作为参数.在破坏的集成上,因为真正的类没有测试为null.现在,在构建这些类时,这并不是什么大不了的事,因为你在构建时测试两端,但如果设计需要在两个月之后发展,当你倾向于忘记细节时,你将如何测试之间的交互这两组对象(通过模拟与实际实现测试的对象)？

潜在的问题似乎是重复(即违反DRY原则),期望实际上保留在两个地方,虽然关系是概念性的,没有实际的重复代码.

[在Aaron Digulla对他的回答进行第二次编辑后编辑]:

是的,这正是我正在做的事情(除了在通过DBUnit测试的类中与DB进行进一步的交互,并且在测试期间与数据库交互,但它是相同的想法).所以现在,我们需要修改数据库行为,以便结果不同.使用模拟的测试将继续通过,除非1)有人记得或2)它在集成中断.因此,数据库的存储过程返回值(比如)基本上在模拟的测试数据中重复.现在困扰我的重复是逻辑是重复的,它是对DRY的微妙违反.它可能就是这样(毕竟有一个集成测试的原因),但我感觉到我错过了一些东西.

[编辑开始赏金]

阅读与Aaron的互动得到了问题的重点,但我真正想要的是如何避免或管理明显的重复,以便真正的类的行为的变化将显示在与模拟交互的单元测试作为破坏的东西.显然,这不会自动发生,但可能有一种方法可以正确设计场景.

[关于授予赏金的编辑]

感谢所有花时间回答问题的人.获胜者告诉我一些关于如何考虑在两层之间传递数据的新内容,并首先得到答案.

从根本上说，您是在寻求不可能。您正在要求您的单元测试来预测并在您更改外部资源的行为时通知您。如果不编写测试以产生新的行为，他们怎么知道？

您正在描述的是添加一个必须测试的全新状态-现在从数据库中出来了一些对象，而不是空结果。您的测试套件可能如何知道被测试对象对于某些新的随机对象应具有的预期行为？您需要编写一个新测试。

正如您所评论的，该模拟并非“行为异常”。模拟完全按照您设置的方式进行。规范更改的事实与模拟无关。在这种情况下，唯一的问题是实施更改的人忘记了更新单元测试。实际上，我不太确定您为什么认为存在重复的担忧。

向系统添加一些新的返回结果的编码器负责添加单元测试以处理这种情况。如果该代码还100％确保没有办法立即返回空结果，那么他还可以删除旧的单元测试。但是你为什么呢？单元测试正确描述了被测对象收到空结果时的行为。如果将系统的后端更改为某些确实返回null的新数据库，会发生什么情况？如果规范改回返回null怎么办？您最好还是继续进行测试，因为就您的对象而言，它确实可以从外部资源中获得任何回报，并且它应该能够妥善处理所有可能的情况。

模拟的整个目的是使测试与实际资源脱钩。它不会自动避免您将错误引入系统。如果您的单元测试准确地描述了收到空值时的行为，那就太好了！但是此测试不应了解任何其他状态，当然也不应以某种方式得知该外部资源将不再发送空值。

如果您正在执行正确的松耦合设计，则您的系统可能具有您可以想象的任何后端。您不应该只考虑一种外部资源来编写测试。如果您添加了一些使用实际数据库的集成测试，从而消除了模拟层，这听起来可能会更快乐。在进行构建或完整性/烟雾测试时，这始终是一个好主意，但对于日常开发通常会造成阻碍。