Skip to main content

Unit Testing your TBBs

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.


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.


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");

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


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(thisnew RenderedItem(
            new ResolvedItem(itemToRender, template),
            new RenderInstruction(_session) { RenderMode = RenderMode.PreviewDynamic }


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:

public void Run() {
    typeof(Engine).GetMethod("TransformPackage"BindingFlags.Instance | BindingFlags.NonPublic)
        .Invoke(thisnew 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 });


Jeremy Simmons said…
have you done any unit testing work with the Event System? Have you mocked any other classes?
Unknown said…
Unfortunately not, but there goes a good blog post idea ;) Stay tuned...

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);
Unknown said…
For implementing the unit test, session object is used which implies that you must have CME installed on the machine where you are running the unit test. CME may not be available on all developer machine so using this unit test implementation is not possible.
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?

Popular posts from this blog

Toolkit - Dynamic Content Queries

This post if part of a series about the  File System Toolkit  - a custom content delivery API for SDL Tridion. This post presents the Dynamic Content Query capability. The requirements for the Toolkit API are that it should be able to provide CustomMeta queries, pagination, and sorting -- all on the file system, without the use third party tools (database, search engines, indexers, etc). Therefore I had to implement a simple database engine and indexer -- which is described in more detail in post Writing My Own Database Engine . The querying logic does not make use of cache. This means the query logic is executed every time. When models are requested, the models are however retrieved using the ModelFactory and those are cached. Query Class This is the main class for dynamic content queries. It is the entry point into the execution logic of a query. The class takes as parameter a Criterion (presented below) which triggers the execution of query in all sub-criteria of a Criterio

A Implementation - Custom Binary Publisher

The default way to publish binaries in DD4T is implemented in class DD4T.Templates.Base.Utils.BinaryPublisher and uses method RenderedItem.AddBinary(Component) . This produces binaries that have their TCM URI as suffix in their filename. In my recent project, we had a requirement that binary file names should be clean (without the TCM URI suffix). Therefore, it was time to modify the way DD4T was publishing binaries. The method in charge with publishing binaries is called PublishItem and is defined in class BinaryPublisher . I therefore extended the BinaryPublisher and overrode method PublishItem. public class CustomBinaryPublisher : BinaryPublisher { private Template currentTemplate; private TcmUri structureGroupUri; In its simplest form, method PublishItem just takes the item and passes it to the AddBinary. In order to accomplish the requirement, we must specify a filename while publishing. This is the file name part of the binary path of Component.BinaryConten

Scaling Policies

This post is part of a bigger topic Autoscaling Publishers in AWS . In a previous post we talked about the Auto Scaling Groups , but we didn't go into details on the Scaling Policies. This is the purpose of this blog post. As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values. We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group. The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the