【问题标题】:How to automate testing of Tridion templates (with TOM.NET)如何自动化测试 Tridion 模板(使用 TOM.NET)
【发布时间】:2012-03-31 23:28:40
【问题描述】:

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

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

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

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

还有其他想法吗?

【问题讨论】:

    标签: testing tridion


    【解决方案1】:

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

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

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

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

    【讨论】:

    • 我认为这是最简单的解决方案,并且可以通过提到的其他想法轻松扩展(隔离代码,使用 Core Service TestRunner 等)
    【解决方案2】:

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

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

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

    【讨论】:

      【解决方案3】:

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

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

      我认为,仅通过使用这种方法的单元测试,您就可以得到大量 TBB 的覆盖率。

      【讨论】:

      • 实际上使用 Microsoft Moles(目前是 Fakes research.microsoft.com/en-us/projects/moles)我设法创建了 MockEngine 和 MockPackage,但在大多数 TBB 中,其他常见类(例如 Component、Schema、ItemFields)最终成为最大的问题,因为它们' 几乎不可能模拟(您最终会模拟所有内容并只是测试您的模拟,即 MockPackage 返回带有 MockSchema 的 MockComponent)。我同意您可以通过隔离非 TOM.Net 代码来获得相当多的代码覆盖率,例如进行 XML 转换的 TBB 通常很容易测试。
      • 我也试过 Moles。看起来不错,但我遇到了一些问题,可能会在它离开研究时解决
      • @Peter - 让这些类对模拟和其他方法更加开放肯定会很棒。尽管我已经转向其他技术,但这些限制总是让我觉得没有必要。
      • 为什么需要模拟项目类型(组件、架构等)?在大多数情况下,这些都是相当简单的数据类,它们可以从 XML 数据结构中对其自身进行初始化。只需将 XML 文件存储在 VCS 中并在单元测试中加载它们。
      【解决方案4】:

      在一个客户处,我看到一个实现,其中测试调用 Template Builder 使用的相同 Web 服务,他们使用这些来执行模板、评估结果等。

      可能值得探索。

      【讨论】:

      • 想必这都是逆向工程的。如果这个 API 被记录和支持,我们都会受益。
      【解决方案5】:

      我建议编写您自己的 TestRunner,有两个目标:创建测试数据并运行测试。

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

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

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

      【讨论】:

        【解决方案6】:

        无论您使用何种方法,我都认为您的问题完全与技术无关(在 Tridion 的背景下思考)。

        问题是你正在修改一个在多个地方使用的东西(组件/页面模板),而这些地方需要在你推送之前进行测试 这是一个有效的变化。

        即使您进行了适当的更改,假设代码运行良好并且您有结果,可能不是消耗您的其他 TBB 所期望的结果 输出。

        不幸的是,这就是问题本身:( 如果问题是您必须使用该 TBB 测试所有模板,那仍然是一个没有解决方案的问题。 如果问题是您不想通过更改/测试影响当前平台,也不想干扰正在进行的其他开发 是一个不同的场景。

        我将通过创建一个单独的出版物来解决第二个问题,该出版物继承自具有要测试的有效代码/数据的出版物 (或提前创建),在那里进行更改并进行测试。 如果您将 TBB 用作许多组件/页面模板的一部分,这种方法是有意义的。

        如果您在前端有足够的粒度(您的 tbb 会生成一段原子代码),那么场景的复杂性会稍微低一些 减少了,但您仍然必须测试所有场景

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2014-07-18
          • 1970-01-01
          • 2018-06-22
          • 1970-01-01
          • 2011-07-22
          相关资源
          最近更新 更多