2

I was trying to create a derived class for Engine abstract class but ended up with the below error.

'{Derived Class}' does not implement inherited abstract member 'Tridion.ContentManager.Templating.Engine.CheckInitialized()'

Could someone help me to derive Engine class so that i can mock this object for my Unit testing framework.
Note : CheckInitialized() is not visible in Engine class and unable to override in derived class.

  • It seems that CheckInitialized() is an abstract internal method. In this case i will not be able to inherit the Engine class from other assembly. is there any work around. – Jaison Prabhu Doss Apr 22 '16 at 6:33
  • Why would you like to inherit engine class? Can you please share your scenario? – Hiren Kaku Apr 22 '16 at 6:35
  • @Hiren : As said, am writing a unit testing framework using MS Fakes which expects all classes to be public with default constructor. So i writing wrapper classes that inherit Tridion classes, so that i can mock Tridion objects using my wrapper classes and validate my custom functionality without Tridion dependency. – Jaison Prabhu Doss Apr 22 '16 at 8:32
  • 1
    I think the only way to do that is with Moles I think msdn.microsoft.com/en-us/library/ff798506.aspx but I would guess that this is going to be a lot of effort for little gain. I think you'd get more value from sonar code quality checks and some manual tests. – Rob Stevenson-Leggett Apr 22 '16 at 17:32
  • I agree with Rob on more effort but there is no gain. In the past we have tried all these and still not able to do unit testing. – Hiren Kaku Apr 23 '16 at 19:25
3

Microsoft Fakes (formerly known as Moles) will allow you to instantiate your own Engine class, but as Rob says, it's a lot of effort for little gain. I once succeeded in this using Moles, but just having the engine isn't really enough. You will very rapidly find yourself mocking all sorts of other things that Tridion provides for you via the engine, and you'll probably be writing very much more test code than subject code.

Unit testing and mocking are techniques more suited to object oriented programming, where your test subject is a class, and ideally one that has been factored to a suitable scale. With templating, what you actually need to test is a transformation. To do this, the approach is to have known inputs and to make assertions about the outputs. Of course, you want to keep the scope of each test as small and isolated as possible, just as you would with classical unit testing.

For testing templates, this means creating test components, and some scaffolding templating to allow you to isolate your test cases. For example, you might have a page template that emits nothing but a single component presentation. A web testing framework like Selenium will allow you to make assertions against the outputs. It's not unit testing, but it is automated (or automatable).

If you are interested in testing template building blocks, you might wish to look at the T-Cubed framework, which allows you to control what is in the package before the TBB is executed, and make assertions about what is in the package afterwards.

In the last couple of years, it has become very clear that the future of templating is in the (MVC) web applications themselves rather than on the Content Manager. One of the drivers for this shift of architectures is the difficulty of automated testing using the old approach. With the templating in the application, standard testing techniques can be used, and you'll never need to consider mocking the engine or the package.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.