作为参数传递给类的关联对可测试性有什么影响？

我正在处理OO设计问题。我会尽力专注于我感到困惑的部分，并用文本解释它，而不是提供代码。作为参数传递给类的关联对可测试性有什么影响？

我有一个名为SalesPolicy的类，它包含一个TaxPolicy列表。 TaxPolicy是一个抽象类，它表示名称和税率作为属性的税收政策。 TaxPolicy包含一个名为accept的抽象方法。 TaxPolicy的具体实现必须实现accept方法并提供决定何时适用TaxPolicy的逻辑。

我有另一个名为SalesEngine的类。 SalesEngine具有SalesPolicy，SalesPolicy是SalesEngine构造函数的参数之一。 SalesEngine通过调用accept方法决定SalesPolicy中的TaxPolicy列表中的TaxPolicy是否适用于某个项目，然后相应地计算税额。如前所述，SalesPolicy包含一个属性，它是一个TaxPolicy列表和一个添加到列表的方法。

我需要知道的是，是否可以为SalesEngine类使用类似SalesPolicy的参数。从可测试代码的角度来看，这会产生什么影响？

来源

2012-08-04 CKing

我认为这是完全正常的有这样一个场景：

public SalesEngine(SalesPolicy policy) { ... }

如果当正在创建SalesEngine用户或任何人已经知道他们想要使用什么SalesPolicy。

另一种情况可能是有价值的，包括是用户不不知道他们想要通过添加默认的构造函数在创建SalesEngine的时间来使用，你可以做什么SalesPolicy的情况和setter方法：

// default construtor 
public SalesEngine() { ... } 

// sets the sales policy 
public void setSalesPolicy(SalesPolicy policy){ ... }

来源

2012-08-04 13:29:00

谢谢你将文本翻译成代码。那对可测试性的影响呢？测试SalesEngine类的测试用例将被迫首先创建SalesPolicy。这间接意味着测试用例必须创建至少一个TaxPolicy才能添加到SalesPolicy！ – CKing 2012-08-04 13:33:44

我认为你上面描述的是两个单独的测试用例。其中一个没有创建SalesPolicy，在这种情况下，accept（）方法可能什么也不做，另一个方法是必须在SalesEngine之前创建一个SalesPolicy。这些听起来都很正常;这就是JUnit中'@ Before'标签的用途，它们允许您为测试初始化场景。 – 2012-08-04 13:46:48

SalesEngine不包含接受方法。 SalesEngine遍历SalesPolicy持有的List 中的TaxPolicy对象。然后，它将每个购买的商品逐个传递给每个TaxPolicy中的accept方法，并根据TaxPolicy计算商品的税额。我们基本上在考虑2个级别的迭代，对于每个项目 - >对于每个策略 - >如果应用策略 - >计算税收 – CKing 2012-08-04 13:52:07

我与亨特的回答你的描述听起来合理的同意（而且，取决于它如何被使用，它可能会以允许以后添加的SalesPolicy是有用的）。所以在这里我将解答你关于测试的问题。简而言之，它并没有真正改变太多。

假设SalesEngine需要一个SalesPolicy对象来完成它的事情，它必须以某种方式得到它。推测测试困难在于测试SalesPolicy对象的代表范围。但是，无论是将它作为构造函数的一部分还是稍后添加它，都不会使它更容易或更难。

另一方面，如果SalesEngine并不总是需要SalesPolicy才能工作，那么您绝对应该采用Hunter的建议。这将是一个更合适的界面，并且可以在不需要SalesPolicy的情况下减轻测试负担。

来源

2012-08-04 13:38:48 David

作为参数传递给类的关联对可测试性有什么影响？

回答

相关问题