我在模板项目中经常出现问题。除了在Template Builder中运行模板之外，我无法以任何其他方式测试我的工作。如果我正在处理在几个不同模板上使用的TBB，这是一个主要问题，因为这意味着在更改TBB中的代码后，我应该重新测试所有模板（并且可能有几个不同的页面/组件，因为可能存在根据内容略有不同的情况。）
正如您在大型项目中看到的那样，TBB被重复使用时，由于需要进行大量测试而需要花费大量时间，因此我很想找到解决方案。我知道使用当前的TOM.NET（大多数类/方法是内部的）几乎不可能进行单元测试，那么实现自动测试的替代方式是什么？
我研究过的一个解决方案是使用Core Service启动带有一些测试内容的模板的渲染过程，然后检查输出是否符合预期，但实现这一点需要相当多的代码，从而产生不必要的开销（我认为它仍然比手动重新测试案例花费的时间少。此外，这并不能真正允许您测试单个TBB，除非您（以编程方式）使用单个（或子集）TBB创建单独的模板。这个解决方案的好处是你可以在开发时在本地笔记本电脑上运行测试，假设你可以连接到Tridion-server（在运行测试之前你仍然需要将你的代码上传到Tridion，所以它不是完全理想的解决方案）。
我知道其他选择是使用DD4T / CWA，你可以在前端处理所有测试，因为模板（通常）非常简单。
还有其他想法吗？
答案 0 :(得分：6)
我同意重点是自动测试，而不是单元测试（毕竟，这主要是关于面向对象的编程）。使用Tridion工作，它是关于转换数据。测试数据转换所需的是具有已知输入，并能够对输出进行断言。多年来我尝试了各种方法，但到目前为止最有效的方法如下：
1）对于每个模板，将测试内容保存在专用文件夹中，并在专用结构组中测试页面。内容是测试的输入，除非测试要求发生变化，否则不打算更改。 2）将组件放在页面上。发布页面。保持简单：您通常可以拥有单个测试场景的页面。如果有帮助，您可以自动发布页面。 3）使用Web测试工具验证输出。这可能是HtmlUnit，Selenium或其他什么。
基本上 - Tridion是执行转换的引擎。您不需要为此部件提供专门的测试执行引擎，尽管使用它来测试输出很有用。
嘲弄这个包装听起来很有吸引力，但正如Vesa所说，它可以变成大量的工作。我概述的简单方法在实践中起作用，并在一个重要项目中得到证实。如果你愿意，可以在主题上添加变体：我考虑过的一件事，但从未在项目上做过，就是使用蓝图为你提供更多的隔离。例如，您可以通过本地化组件模板来测试页面模板，以生成静态和可预测的组件演示。我只想说，一旦你从单元测试方法的包袱中解脱出来，就有足够的创造空间。
答案 1 :(得分：2)
我对CoreService场景有一些经验。您只需要编写一些帮助程序来上传模板，创建coumpound模板并运行它。然而，棘手的部分是验证。
您需要编写一些可以帮助您进行验证的测试模板。一种方法是编写您将传递预期值的.Net模板，它将进行验证。另一种方法是编写将从包打印值的DreamWeaver模板，然后您将根据预期进行检查。此方法的优点是，这些值将作为CoreService Render操作的结果返回给您，您可以在客户端进行所有验证。
但最困难的部分是数据集创建。这可能需要大部分时间。
答案 2 :(得分：2)
您可以尝试隔离可以进行单元测试的类中的大部分代码。
我想这里的主要问题是发动机和包装是密封的，所以你不能轻易地模拟它们。但是您可以最小化与这些对象的交互，并将代码的内容放在采用相关输入的类中，并返回应该放在包中的输出等。
我认为你可以通过这种方法从单元测试中获得很多TBB的报道。
答案 3 :(得分：2)
在一位客户，我见过一个实现，其中测试调用Template Builder使用的相同Web服务，并且他们使用这些服务来执行模板，评估结果等。
可能值得探索。
答案 4 :(得分：2)
我建议您编写自己的TestRunner，其中包含2个目标：创建测试数据并运行测试。
创建测试数据：我们的想法是创建一个样本数据集（所有字段，一些字段，并且仅自动创建必填字段）。 （使用Chuck Norris引用而不是lorem ipsum的加分点）。 Sample内容的标题使用命名方案 - 如[TestContent]和/或在其自己的文件夹中附加元数据（稍后查找）。
创建测试页面：找到TestContent。使用GetListUsingItems查找使用模板的页面。复制页面，并将其粘贴到TestContent StructureGroup中，保存。打开页面，添加测试内容，删除其他内容，并使用特殊命名架构保存页面。
运行测试：找到TestContent，预览每一个，写出包含渲染时间，成功状态和字符数的报告。
答案 5 :(得分：1)
无论您使用哪种方法，我认为您的问题完全与技术无关（在Tridion背景下思考）。
问题是你正在修改在多个地方使用的一件事（组件/页面模板），并且在推送之前需要测试那些地方 这是一个有效的变化。
即使你做了适当的更改，假设代码运行正常并且你有结果，也许不是消耗你的其他TBB所期望的结果 输出
不幸的是，这是问题本身:( 如果问题是您必须使用该TBB测试所有模板，那么这仍然是一个没有解决方案的问题。 如果问题是您不希望通过更改/测试影响当前平台，也不会干扰正在进行的其他开发 是一个不同的场景。
我会通过创建一个单独的出版物来解决第二个出版物，该出版物继承了具有有效代码/数据的出版物以进行测试 （或预先创建），在那里进行更改并进行测试。 如果您将TBB用作许多组件/页面模板的一部分，则此方法很有意义。
如果您拥有前端的粒度（您的tbb生成一个原子代码片段），那么场景的复杂性会略有下降 减少了，但你还是要测试所有场景