10

我在模板项目中经常遇到问题。除了在模板生成器中运行模板之外，我无法真正测试我的工作。如果我正在处理用于多个不同模板的 TBB，这是一个主要问题，因为这意味着在更改 TBB 中的代码后，我应该重新测试所有模板（可能还有几个不同的页面/组件）根据内容略有不同的情况）。

正如您在大型项目中看到的那样，TBB 被大量重用，由于需要进行大量测试，因此更改它们会花费大量时间，我很想为此找到解决方案。我知道使用当前的 TOM.NET（大多数类/方法是内部的）几乎不可能进行单元测试，那么实现自动化测试的替代方法是什么？

我研究过的一种解决方案是使用核心服务来启动带有一些测试内容的模板的渲染过程，然后检查输出是否符合预期，但实现这一点需要大量代码，因此会产生不必要的开销（我认为仍然比手动重新测试案例花费的时间更少）。此外，除非您（以编程方式）使用单个（或一部分）TBB 创建单独的模板，否则这实际上并不允许您测试单个 TBB。该解决方案的好处是您可以在开发时在本地笔记本电脑上运行测试，假设您可以连接到 Tridion-server（在运行测试之前您仍然需要将代码上传到 Tridion，因此它不是完全理想的解决方案）。

我知道另一种选择是使用 DD4T/CWA，您几乎可以在前端处理所有测试，因为模板（通常）非常简单。

还有其他想法吗？

4

6 回答 6

6

我同意重点是自动化测试而不是单元测试（毕竟，单元测试主要是关于面向对象的编程）。Tridion 的工作就是转换数据。测试数据转换所需的是具有已知的输入，并能够对输出做出断言。多年来我尝试了各种方法，但迄今为止最有效的方法如下：

1) 对于每个模板，将测试内容保存在专用文件夹中，并将测试页面保存在专用结构组中。内容是测试的输入，除非测试要求发生变化，否则不会更改。2) 将组件放在页面上。发布页面。保持简单：您通常可以为单个测试场景创建一个页面。如果有帮助，您可以自动发布页面。3）使用网络测试工具来验证输出。这可能是 HtmlUnit、Selenium 或其他。

基本上 - Tridion 是执行转换的引擎。这部分不需要专门的测试执行引擎，尽管使用一个来测试输出很有用。

嘲笑这个包裹听起来很有吸引力，但正如 Vesa 所说，它可能会变成大量的工作。我概述的简单方法在实践中有效，并在一个重要项目中得到证明。如果您愿意，您可以在主题上添加变体：我考虑过但从未在项目中做过的一件事是使用蓝图为您提供更多隔离。例如，您可以通过本地化组件模板来生成静态和可预测的组件演示来测试您的页面模板。只要你从单元测试方法的包袱中解脱出来，就有足够的创造力发挥空间。

于 2012-03-15T21:00:38.277 回答
2

我对 CoreService 场景有一些经验。您只需要编写一些帮助程序来上传您的模板、创建复合模板并运行它。然而，棘手的部分是验证。

您将需要编写一些测试模板来帮助您进行验证。一种方法是编写 .Net 模板，您将向其传递预期值并进行验证。另一种方法是编写 DreamWeaver 模板，该模板将打印包中的值，然后您将根据预期检查它。此方法的优点是这些值将作为 CoreService Render 操作的结果返回给您，您可以在客户端进行所有验证。

但最困难的部分是数据集的创建。这可能会占用您大部分时间。

于 2012-03-15T13:26:34.610 回答
2

您可以尝试将大部分代码隔离在可以进行单元测试的类中。

我想这里的主要问题是引擎和包是密封的，所以你不能轻易地模拟它们。但是您可以最小化与这些对象的交互，并将代码的主体放在接受相关输入并返回应放入包中的输出的类中等。

我认为你可以通过这种方法从单元测试中获得很多关于你的 TBB 的报道。

于 2012-03-15T13:31:45.013 回答
2

在一个客户中，我看到一个实现，其中测试调用模板生成器使用的相同 web 服务，他们使用这些来执行模板、评估结果等。

可能值得探索。

于 2012-03-15T14:34:04.593 回答
2

我建议编写你自己的 TestRunner 有两个目标：创建测试数据和运行测试。

创建测试数据：这个想法是创建一个样本数据集（所有字段，一些字段，只有自动必填字段）。（使用 Chuck Norris 引用而不是 lorem ipsum 的奖励积分）。示例内容的标题使用命名方案 - 如 [TestContent] 和/或位于其自己的文件夹中，并附有元数据（稍后查找）。

创建测试页面：找到 TestContent。使用 GetListUsingItems 查找使用模板的页面。复制页面，并将其粘贴到 TestContent StructureGroup 中，保存。打开页面，添加测试内容，删除其他内容，并使用特殊命名模式保存页面。

运行测试：找到 TestContent，预览每一个，写出带有渲染时间、成功状态和字符数的报告。

于 2012-03-15T14:39:54.060 回答
1

无论您使用哪种方法，我都认为您的问题完全与技术无关（在 Tridion 的背景下思考）。

The problem is that you are modifying one thing that is used in multiple places (Component/Page Templates) and those places need to be tested before you push that as a valid change.

Even if you do proper changes, assume the code runs fine and you have a result, maybe is not the result that is expected by other TBBs that consume your output.

That is the problem itself unfortunately :( If the problem is that you have to test all the Templates using that TBB, that is still a problem with no solution. If the problem is that you don't want to impact the current platform with your changes/testing nor interfere with other developments going on is a different scenario.

I would solve the second one by creating a separate publication inheriting from the publication with valid code/data to test (or have that created in advance), make your changes there and test. This approach makes sense if you are using the TBB as part of many Component/Page Templates.

If you have the luxury of the granularity in the front end (your tbb produces an atomic piece of code) the complexity of the scenario would be slightly reduced, but you still have to test all the scenarios anyway

于 2012-03-30T02:21:19.627 回答