组合不是可测试性差吗？

Question

通常，组合物和聚合物的处理方式相同吗？但它们是不同的，选择使用哪一个变化很大？ 例如：

我认为聚合对于测试来说是理想的。但是成分不是。

依赖性的维护在使用聚合时很痛苦，但在使用Composition时则较少。

那么有相同的观点吗？哪一个选择，应该只基于“part-of”和“has-a”。

Answer 1

聚合，即指向，具有句柄，具有比构图更多的自由度，即包含。

聚合可能出错的事情：子对象过早被破坏，泄漏，链接从未建立，另一个对象认为它拥有独占所有权并对其进行修改。

编译器通常更容易检查组合（例如在C ++中），并且更容易检查，因为可能的未初始化状态较少，可能的损坏方式较少。

一般来说，更喜欢作文。

编辑 易于编写测试的重要性低于良好覆盖所需的测试次数。如果您的测试策略导致您做出增加故障模式的设计决策，那么它就会反向运行。

单元测试显然不会暴露集成中的缺陷。最好通过客户端对象上的测试子集来测试子对象。记录每个测试如何将特定行为委托给子对象，以及如何在其自然环境中对其进行有效和准确的测试。

当然，我知道有很多管理人员将拥有不少于1000行的拇指缠绕代码，除了绑定和破坏整体设计之外什么都不做。

Answer 2

我的帖子遵循的定义是here，因为关联，聚合和组合有多种定义。

我觉得每个人都有自己的用途：

聚合：由对象适配器设计模式使用

组合：由复合设计模式使用

关联：由许多设计模式使用，例如观察者

它确实依赖于上下文。

开始测试，我认为测试更松散耦合的组件更容易。聚合促进了设计，这些设计比基于聚合的设计更加失去耦合。由于测试需要使用实验/测试提供的对象配置代码组件。我会说聚合更好。您可以灵活地使用不同的测试对象配置对象。

Answer 3

如果您对形成合成的元素进行单元测试以证明独立的正确性，那么在测试合成单元时，您只需要测试合成单元功能，而无需担心适用于合成元素的测试覆盖率。 / p>

也就是说，如果您自下而上测试，可测试性可能没有问题。在测试合成元素时，您将组合单元（使用测试工具）存根，而不是反过来。然后，对组合单元的测试使用混凝土单元而不是短截线。