单元测试 – 使用Sitecore 7和TFS 2012 CI进行TDD

所以,使用Sitecore进行测试.这是一个特殊主题,我已经找到了有关它的分配材料. (Sitecore开发第8章, Alistair Deneys blog, NextDigital blog, iStern blog,……)但是在大多数情况下,他们会使用NUnit和自定义测试跑步者等…对我来说最有用(对我而言)到目前为止 iStern blog使用Microsoft Fakes模拟Sitecore.但这真的是要走的路吗？

我很惊讶Hedgehog TDS系统能够与TFS进行如此深入的集成,并且能够在Sitecore开发中进行CI,因此没有更多关于如何利用该系统来设置TFS执行的可靠测试(尚未).

我们正在准备一个大型新项目,现在使用Sitecore处理前端用户交互,其中使用的数据比WCF服务落后95％.所以这部分可以很容易地测试和TDD开发.这是Sitecore中需要测试的最后5％(可悲地包括最高的商业价值,即在线支付).我们是否可以对sitecore有足够的熟悉知识来嘲笑它？我倾向于不考虑……如果是这样,那么我们如何针对sitecore对我们的TFS CI构建进行结论性测试？

最后但并非最不重要的是,我感觉到目前发现的信息可能有点过时(maily看到了NextDigital blog的评论),Sitecore 7是否开辟了解决这个问题的新方法？

对于那些将此视为哲学而非技术问题的人：对此只能有一个答案,那就是使用能够在TFS CI中运行的Microsoft测试框架的方法的技术准确定义测试为Sitecore编写的代码的环境.

微软走错了吗？在我看来,没有. Microsoft fakes允许您测试不可测试的代码.如果您正确地设计了解决方案,那么标准的模拟框架就足够了.

我们是否可以对sitecore有足够的熟悉知识来嘲笑它？这是一个棘手的问题.除非第三方库是专门为它设计的,并且你会认为它是“稳定的依赖”,你不应该试图嘲笑它.相反,用你自己的类和抽象包装它并嘲笑它们.

看看Synthesis和Glass Mapper.它们是对象映射框架,允许您将Sitecore项映射到接口,同时保持页面编辑器支持. Glass,特别是Sitecore.Context周围有一个可以模拟的包装器.合成应该是非常可测试的,但我还没有尝试过.

使用其中一个映射框架和良好的SOLID设计,您应该能够使大部分代码可测试.请记住,解决方案边缘的类应该足够简单,不需要测试.