One of the reasons I was Messing with the Engine is testing. I wanted to write unit tests for Tridion Template Building Blocks and for that I needed the possibility to run my templates outside of the Content Manager.
In order to run templates in Tridion CM, one would need an instance of the Engine and Package objects. The Package is quite simple, as you would simply instantiate one using Package(Engine engine) constructor. Getting an instance of Engine on the other hand was quite excruciating -- somebody in Tridion R&D put it great effort in making that class final, sealed, internal, unextendable, unwrappable, private constructors, <fill in here your preferred C# access modifier>, etc. Well, too bad for all that effort, because one way or another there is always a solution -- in my case, enter reflection... but more on that later.
In the code above, a Page is rendered with a PT. For that TestEngine creates its own Package and then, by calling Run(), it simply fires off the template rendering process. Once Run() finishes, all TBBs in the template would have executed and the Package can be inspected for getting the success/failure status of the unit test.
With the current implementation, the whole template is executed, but also more fine-grained approach is possible -- where only a specified TBB would be executed.
public class TestEngine : TemplatingRenderer
Now that I have an instance of the Engine, let's execute the template on a Page or Component. There is one public method Render which kicks off the entire execution, but it does too much for me -- I need something more fine-grained and where I can have access to the Package. This method is Engine.TransformPackage(Template, Package), which only deals with the rendering part of the process. The problem with it is its visibility - internal. Here comes hack #2 and again reflection comes to the rescue:
Notice the property Package that I'm passing to TransfrormPackage. This is basically the object I create and the one that I'm inspecting at the end of the template rendition.
public class TestEngine : TemplatingRenderer {
Approach
The approach is to run templates from an external project (be it stand-alone application, or a testing framework of your choice) and be able to check the Package contents at different stages in the execution. Then I would simply compare some expected Package items or even the Output item to contain some expected results.In order to run templates in Tridion CM, one would need an instance of the Engine and Package objects. The Package is quite simple, as you would simply instantiate one using Package(Engine engine) constructor. Getting an instance of Engine on the other hand was quite excruciating -- somebody in Tridion R&D put it great effort in making that class final, sealed, internal, unextendable, unwrappable, private constructors, <fill in here your preferred C# access modifier>, etc. Well, too bad for all that effort, because one way or another there is always a solution -- in my case, enter reflection... but more on that later.
Usage
I came up with my own engine implementation TestEngine and I am able to run it on a Page or Component while passing the Page Template to render with, or Component Template respectively:
TestEngine engine = new TestEngine("tcm:20-102-64", "tcm:20-707-128");
engine.Run();
In the code above, a Page is rendered with a PT. For that TestEngine creates its own Package and then, by calling Run(), it simply fires off the template rendering process. Once Run() finishes, all TBBs in the template would have executed and the Package can be inspected for getting the success/failure status of the unit test.
foreach (KeyValuePair<string, Item>
pair in engine.Package.GetEntries()) {
Item item = pair.Value;
Console.WriteLine(string.Format("Item {0} | Type {1} | Content {2}",
pair.Key, item.ContentType,
item.GetAsString()));
}
With the current implementation, the whole template is executed, but also more fine-grained approach is possible -- where only a specified TBB would be executed.
TestEngine Implementation
But let's see the implementation of TestEngine. It is a TemplatingRenderer specialization:public class TestEngine : TemplatingRenderer
Constructor
TemplatingRenderer contains a bunch of useful logic, which I simply wanted to re-use. But before being able to do so, the Engine has to be initialized, so the Package and RenderedItem members need to be assigned. Again, with Package there is no problem, but _renderedItem is not exposed. Here comes in the first hack -- set _renderedItem using reflection. I do this in the TestEngine constructor:
public TestEngine(string pageOrComponentTcmUri, string templateTcmUri) {
_session = new Session();
itemToRender = _session.GetObject(pageOrComponentTcmUri);
template = _session.GetObject(templateTcmUri) as Template;
typeof(TemplatingRenderer).GetField("_renderedItem", BindingFlags.Instance | BindingFlags.NonPublic)
.SetValue(this, new RenderedItem(
new ResolvedItem(itemToRender, template),
new RenderInstruction(_session) { RenderMode = RenderMode.PreviewDynamic }
)
);
}
Run
public void Run() {
typeof(Engine).GetMethod("TransformPackage", BindingFlags.Instance | BindingFlags.NonPublic)
.Invoke(this, new object[] { Template, Package });
}
Notice the property Package that I'm passing to TransfrormPackage. This is basically the object I create and the one that I'm inspecting at the end of the template rendition.
All Together
Finally, putting it all together, this is the final class:public class TestEngine : TemplatingRenderer {
private IdentifiableObject itemToRender;
public IdentifiableObject ItemToRender {
get { return itemToRender; }
}
private Template template;
public Template Template {
get { return template; }
}
private Package package;
public Package Package {
get {
if
(package == null) {
package = new Package(this);
if
(itemToRender.Id.ItemType == ItemType.Component)
{
Item
item = package.CreateTridionItem(ContentType.Component,
itemToRender);
package.PushItem(Tridion.ContentManager.Templating.Package.ComponentName, item);
} else
{
Item
item = package.CreateTridionItem(ContentType.Page,
itemToRender);
package.PushItem(Tridion.ContentManager.Templating.Package.PageName, item);
}
}
return
package;
}
}
public
TestEngine(string pageOrComponentTcmUri, string templateTcmUri) {
_session = new
Session();
itemToRender =
_session.GetObject(pageOrComponentTcmUri);
template =
_session.GetObject(templateTcmUri) as Template;
typeof(TemplatingRenderer).GetField("_renderedItem", BindingFlags.Instance | BindingFlags.NonPublic)
.SetValue(this,
new RenderedItem(
new
ResolvedItem(itemToRender, template),
new
RenderInstruction(_session) { RenderMode = RenderMode.PreviewDynamic }
)
);
}
public void Run() {
typeof(Engine).GetMethod("TransformPackage",
BindingFlags.Instance | BindingFlags.NonPublic)
.Invoke(this,
new object[] {
Template, Package });
}
}
Comments
The approach would be somewhat similar to testing TBBs:
- create a Session object;
- get Tridion item using Session;
- 'fake' a call to the Event System handler method (of course the event phases won't work, because we are not actually in event system context);
As per my understanding, unit testing should be independent of machine.
Can you please suggest any other alternative for implementing unit testing for TBB and Event System?