测试洋葱的内部答案

【问题标题】：Testing the Inner part of the Onion测试洋葱的内部
【发布时间】：2018-01-22 20:16:16
【问题描述】：

我正在使用 DDD 原则构建应用程序。

第一次测试迭代是针对 Onion 的内部部分，即实体和值对象。这不是单元测试，因为没有依赖关系，我相信它不是集成测试，因为我只测试一层，即我没有测试两个或多个层如何集成在一起。

那么它是什么类型的测试呢？

【问题讨论】：

【解决方案1】：

那么它是什么类型的测试呢？

通常，如果您正在测试与应用程序和基础架构问题隔离的域模型（或其中的一部分），那么您所拥有的就是单元测试。

当然，对于什么是“单位”并没有普遍的共识；例如，参见 Martin Fowler 对solitary vs sociable tests 的讨论。

但您可能会考虑一些流行的示例 - Bowling Game kata，并注意到 TDD 的 Chicago style 中的大部分测试首次演示都充实了独立于应用程序和基础架构问题的域逻辑。

在该层通常没有什么要测试的。无论如何，它主要由 POCO 组成。

域实体和域值通常不会这样；如果遵循面向对象的编码风格，有趣的业务行为是与数据组合成对象。

如果您遵循更实用的风格，那么您最终可能会得到无聊的不可变数据（可能是 POCO），而要测试的有趣行为将表示为纯函数。

但在任何一种风格中，这些行为都将成为领域模型的一部分，因此将存在于洋葱的核心中。

表达方式略有不同，您的应用程序的functional core 通常是经过单元测试的。

【讨论】：

【解决方案2】：

在该层通常没有什么要测试的。无论如何，它主要由 POCO 组成。

但是，如果您有复杂的值对象来提供功能并具有明确的依赖关系，那么可能有理由单元测试通过提供最少的必要依赖关系来完成这些测试。单元测试 /p>

任何可以使用而不会产生连锁反应的依赖项都可以按原样使用。如果您想对依赖项进行精细控制，请模拟它们。

但除此之外，没有什么可以在核心中实际测试的。

【讨论】：

请在此处查看此代码：github.com/jbogard/presentations/blob/master/WickedDomainModels/…。您确定要测试 IOfferValueCalculator 是否正常工作？
@w0051977 是的，这是一个更复杂的值对象，具有显式依赖关系，可以从单元测试中受益。
谢谢。我正在考虑通过传入具体的 OfferType 和 ValueCalculator 并断言返回的 Offer 来测试 AssignOffer 方法。这是一个有效的测试还是我应该嘲笑 ValueCalculator？
@w0051977 两者都可以。如果您想要更多地控制预期行为，请模拟您想要控制的行为。任何可以使用而不会产生连锁反应的依赖项都可以按原样使用。
谢谢。如果我模拟传递给类的两个对象，那么我意识到这是一个单元测试。如果我将两个具体对象传递给该方法，这是否是一个集成测试？这是我的最后一个问题，也是我最初的问题。