我在模板项目中经常遇到问题。除了在模板生成器中运行模板之外,我无法真正以任何其他方式测试我的工作。如果我正在处理一个在几个不同的模板上使用的TBB,这将是一个主要的问题,因为这意味着在更改TBB中的代码之后,我应该重新测试所有的模板(并且可能使用几个不同的页面/组件,因为可能会有一些不同的情况,取决于内容)。
正如您所看到的,在大型项目中,TBB被重用了很多,更改它们花费了大量的时间,这是必要的测试量,我很想找到一个解决方案。我知道,使用当前的TOM.NET (大多数类/方法都是内部的),单元测试实际上是不可能的,那么实现自动化测试的替代方法是什么呢?
我已经研究过的一个解决方案是使用Core启动带有一些测试内容的模板的呈现过程,然后检查输出是否如预期的那样,但要实现这一点需要大量代码,从而产生不必要的开销(我认为仍然比手动重新测试这些案例花费更少的时间)。而且,这实际上不允许您测试单个TBB,除非您(以编程方式)使用单个(或其子集)TBB创建单独的模板。这个解决方案的好处是,您可以在开发过程中在本地笔记本上运行测试,前提是您可以连接到Tridion服务器(在运行测试之前,您仍然必须将代码上传到Tridion,所以它并不是完全理想的解决方案)。
我知道另一种选择是使用DD4T/CWA,在这里您可以处理前端的所有测试,因为模板(通常)非常简单。
还有其他想法吗?
发布于 2012-03-15 21:00:38
我同意强调自动化测试而不是单元测试(毕竟,这主要是关于面向对象的编程)。随着Tridion的工作,它是关于数据转换。测试数据转换所需要的是拥有已知的输入,并能够对输出进行断言。多年来,我尝试过各种方法,但迄今为止最有效的方法是:
1)对于每个模板,将测试内容保存在专用文件夹中,并将测试页保存在专用结构组中。内容是测试的输入,除非测试需求发生变化,否则不会进行更改。2)将组件放在页面上。把书页发表出来。保持简单:您通常可以为单个测试场景创建一个页面。如果这有帮助,您可以自动发布页面。3)使用web测试工具对输出进行验证。这可能是HtmlUnit,Selenium之类的。
基本上- Tridion是一个执行转换的引擎。对于这个部分,您不需要一个专门的测试执行引擎,尽管使用一个引擎来测试输出是很有用的。
嘲笑这个包听起来很有吸引力,但正如Vesa所说,它可以变成大量的工作。我在实践中概述了工作的简单方法,并在一个重大项目上得到了证明。如果你喜欢的话,你可以在主题上添加变化:我考虑过但从未在项目上做过的一件事,就是使用蓝图给你更多的隔离。例如,您可以通过本地化组件模板来生成静态和可预测的组件演示文稿来测试页面模板。只需说,一旦您摆脱了单元测试方法的包袱,就有足够的创造力空间。
发布于 2012-03-15 13:26:34
我对CoreService场景有一些经验。你只需要写一些帮助上传你的模板,创建耦合模板并运行它。然而,棘手的部分是验证。
您需要编写一些测试模板,以帮助您进行验证。一种方法是编写.Net模板,您将向其传递期望值,并进行验证。另一种方法是编写DreamWeaver模板,该模板将从包中打印值,然后根据预期对其进行检查。该方法的优点是,这些值将作为CoreService呈现操作的结果返回给您,并且您可以在客户端执行所有验证。
但最困难的部分是数据集的创建。这可能会占用你大部分时间。
发布于 2012-03-15 13:31:45
您可以尝试将大多数代码隔离到可以进行单元测试的类中。
我想这里的主要问题是引擎和包装是密封的,所以你不能轻易地模仿它们。但是,您可以将与这些对象的交互最小化,并将代码的内容放入接受相关输入的类中,并返回应该放在包中的输出等。
我认为您可以从使用这种方法的单元测试中获得大量TBB的信息。
https://stackoverflow.com/questions/9720022
复制相似问题