是否可以将基于策略的设计与自动化测试一起使用？

Posted 2023-04-13

【中文标题】是否可以将基于策略的设计与自动化测试一起使用？

【英文标题】：Is it possible to use policy based design together with automated testing?

【发布时间】：2013-04-05 15:32:10

【问题描述】：

我正在开发一个数值模拟库，它以由不同计算算法操作的单个数据集合为中心。算法很复杂，它们具有涉及多个参数的不同状态，并且是可互换的（在某些语义限制下）。

为了避免集合的臃肿接口并启用不同的实现等，我正在考虑使用基于策略的设计。这为集合提供了存储结构、算法、参数、内部内容之间的广泛选择组合。

如果我想象我重新设计了我的通用/面向对象的现有设计使用策略，我该如何选择最佳算法和数据结构？从概念上讲，我需要定义一组策略和一组验证测试用例并执行参数研究。

当使用面向对象编程时，这很容易，因为我可以在运行时确定所有必要的类型及其参数，例如使用一个基于字符串的抽象工厂，其类型名称存储在输入文件中，然后由在一系列测试用例上执行客户端应用程序的外部脚本更改。

如果 N 个策略的组合最终成为 N 个不同的客户端应用程序，我该如何使用策略来做到这一点？

如何以专业的方式完成自动化测试和基于策略的设计？

【问题讨论】：

就像你暗示的那样，在运行时没有办法做到这一点！听起来您需要编写一个脚本来生成所有可能的策略排列，然后以某种方式将其粘贴到您的性能测试代码中。我不知道有什么现成的工具可以做这种事情，但也许其他人会:)

我正在考虑结合外部脚本编辑宏，该脚本将类型名称存储在表中并对其进行置换，然后它调用编译器，然后是一个自动测试套件：客户端应用程序在这种情况下，allways 具有相同的名称。但是我想知道实际使用的是什么？

【参考方案1】：

如果您将算法表示为策略，那么您/应该/已经想到了一个非常统一的界面。您可以想象一个“AlgorithmPolicy”处理数据存储中的一些数据并返回结果的一些表示。

“如果我想象我重新设计了我的通用/面向对象的现有设计使用策略，我该如何选择最佳算法和数据结构？”

如果您的面向对象设计当前使用策略模式（另请参见：四人帮一书），您的策略将简单地替换您使用策略的每个地方。为您设计的不同策略选择“最佳算法”只是为这些策略确定正确的概念结构/界面。 （例如，如果您要使用许多不同的数据存储，请确保从它们添加/删除/获取数据的接口是统一的。在这里，考虑三个示例并找到共性会很有帮助......然后想另一个例子并确保它符合架构。迭代直到感觉正确为止。）

你仍然会有足够的类型检查，只是感觉有点不同（你可能偶尔会遇到一些令人讨厌的编译错误。;）

测试只是为您想要涵盖的每个配置/策略组合编写一些单元测试。无论如何，您可能应该已经在编写这些测试了；主要区别在于您将要尝试使用您指定的接口，而不是针对具体细节。

您可以根据对算法策略的验证来验证不同的存储方法。 （所以，如果我有一些可以以不同方式存储的算法，我可以在 ecah 存储机制的一些测试数据上运行该算法并期望得到相同的结果。）假设你已经指定了接口正确性，你应该只需要为您添加的每个附加存储机制编写一个测试。

再次提醒：如果您能详细了解程序的结构、您需要传入哪些不同的参数等信息，那就太好了。（这些代码中是否有任何开源/即将开源？）

从你所说的，在我看来，你的复杂策略流程可能有这样的界面：

FancyDataStore.Process()

为了测试它，我会写： MockAlgorithmPolicy - 一个非常简单的算法，验证起来很简单。 MockInternalStuffPolicy - 一个非常简单的内部材料策略，不会导致集成/报告任何新内容。 MockStoragePolicy - 一个非常简单的存储策略，满足您的存储接口/不会导致很多问题。

编写一个测试来验证放在一起的模拟... 对于您创建的每个 StoragePolicy，编写一个自动化测试来验证它：

testSomeStoragePolicy 
// has a call to: 
FancyDataStore.Process<MockAlgorithmPolicy, SomeStoragePolicy, MockInternalStuff>() 
// validate... 

这应该证明 SomeStoragePolicy 按预期工作。

那么，对于你的算法，你可以这样写：

testSomeAlgorithmPolicy
FancyDataStore.process<SomeAlgorithmPolicy, MockStoragePolicy, MockInternalStuff>(); 
///Validate. 

等等。 这样，您基本上为每个最终编写的策略编写 1 个测试（这似乎可行且不太荒谬）此外，您始终可以添加额外的单元测试来涵盖其他可能随着时间推移而出现的微妙集成。

如果您正在寻找有关该主题的好书，我建议您阅读“现代 C++ 编程”；它为 C++ 中的策略驱动设计提供了很好的入门知识。

【讨论】：

谢谢，我得出了同样的结论：我将使用基于策略的设计并确定合理的测试配置。对于这些配置，我将让脚本配置模板、编译并执行测试集。感谢您对这本书的提示，我已经阅读了它，但是关于基于策略的设计的章节并没有解释自动测试。 :)