我在模板项目中经常出现问题.除了在Template Builder中运行模板之外,我无法以任何其他方式测试我的工作.如果我正在使用在几个不同模板上使用的TBB,这是一个主要问题,因为这意味着在更改TBB中的代码后,我应该重新测试所有模板(并且可能有几个不同的页面/组件,因为可能存在根据内容略有不同的情况).
正如您在大型项目中看到的那样,TBB被重复使用会大量改变它们需要大量的时间,因为需要大量的测试,我很想找到解决方案.我知道使用当前的TOM.NET(大多数类/方法是内部的)几乎不可能进行单元测试,那么什么可以成为实现自动化测试的替代方法呢？
我研究过的一个解决方案是使用Core Service来启动带有一些测试内容的模板的渲染过程,然后检查输出是否符合预期,但实现这一点需要相当多的代码,从而产生不必要的开销(我认为它仍然比手动重新测试案例花费更少的时间).此外,这并不能真正允许您测试单个TBB,除非您(以编程方式)使用单个(或子集)TBB创建单独的模板.这个解决方案的好处是你可以在开发时在本地笔记本电脑上运行测试,假设你可以连接到Tridion-server(在运行测试之前你仍然需要将你的代码上传到Tridion,所以它不是完全理想的解决方案).
我知道其他选择是使用DD4T/CWA,你可以在前端处理所有测试,因为模板(通常)非常简单.
还有其他想法吗？
我同意重点是自动测试而不是单元测试(毕竟,主要是关于面向对象的编程).使用Tridion工作,它是关于转换数据.测试数据转换所需的是具有已知输入,并能够对输出进行断言.多年来我尝试了各种方法,但到目前为止最有效的方法如下:
1)对于每个模板,将测试内容保存在专用文件夹中,并在专用结构组中测试页面.内容是测试的输入,除非测试要求发生变化,否则不打算更改.2)将组件放在页面上.发布页面.保持简单:您通常可以拥有单个测试场景的页面.如果有帮助,您可以自动发布页面.3)使用Web测试工具验证输出.这可能是HtmlUnit,Selenium或其他什么.
基本上 - Tridion是执行转换的引擎.您不需要为此部件提供专门的测试执行引擎,尽管使用它来测试输出很有用.
模仿包装听起来很有吸引力,但正如Vesa所说,它可以变成大量的工作.我概述的简单方法在实践中起作用,并在一个重要项目中得到证实.如果你愿意,可以在主题上添加变体:我考虑过的一件事,但从未在项目上做过,就是使用蓝图为你提供更多的隔离.例如,您可以通过本地化组件模板来测试页面模板,以生成静态和可预测的组件演示.可以说,一旦你从单元测试方法的包袱中解脱出来,就有足够的创造空间.