I like to know if there is a generic mock object or community project that will provide me the ability to unit test my TOM API C# code following a test driven development approach.

I'm looking for a mock object which contains the base Tridion objects like a Page object without creating test components /objects in Tridion itself.

  • Have you tried using Microsoft Fakes? – Kah Tang Jun 17 '14 at 15:20

Dominic Cronin, Quirijn Slings, and Andrey Marchuk developed a Tridion Template Testing framework called T-Cubed that may be of some assistance: https://github.com/DominicCronin/T-cubed

It's mainly for unit testing templates - so it may not be super helpful for C# that's using TOM.NET, but it's a place to start.


I'll throw another possibility into the mix.

Ideally, in this scenario (in the context of a C# TBB, for example), what you'd want to do is mock out the Engine and Package objects to control their behaviour at runtime - with no need for concrete stubs (or physical test data) for things like Pages - and then make assertions about what interactions your template Transform performs in particular scenarios. Unfortunately, you can't do this to any useful extent, because Engine and Package do not implement an interface you can mock (and their useful methods are not virtual).

I ran across a very similar problem recently when trying to test a service layer that exposed some taxonomy via the CD API - specifically, trying to mock some keywords - and StackOverflow suggested making use of shims, which allow you to dynamically swap out assemblies to give you greater control of otherwise "unmockable" objects. Shims are, however, limited to VS2012/2013 Premium and Ultimate.

See the MS Fakes documentation for more info on using shims.

Beyond this, I think you're going to struggle to do any real unit testing per se as, while you could in theory use factory methods to generate a package that gives you what you need for your tests (even this would limit you to output verification and not allow you to make assertions about mocked method invocations), there's no real way to mock out the Engine.

If you're happy with a more integration-focused style of template testing (arguably more valuable in this kind of scenario anyway), the T-Cubed framework as mentioned by paceaux offers quite a nice solution.

  • A long time ago I used Microsoft Moles (the research predecessor to Fakes) and more or less got it working to mock the package. Apart from the actual mocking being too hard (at the time), a rather bigger shock was exactly how much code I'd have had to have written to even vaguely provide a representation of what a Tridion system does for you. – Dominic Cronin Jul 17 '14 at 19:45

You should consider techniques other than mocking. The point is that with an template building block, you mostly aren't unit testing a self-contained class - actually, you are testing a data transformation. For this, what you need is a variety of known input, the ability to execute your transforms, and some way of testing your output.

Tridion itself is a very powerful tool in this regard. You can create test data. (That's simply a question of having some dedicated folders where this belongs). Tridion provides the means to execute your template building blocks - you might need to host them in some test Component templates or Page templates (or even consider using the Template builder to execute Compound templates with saved input data)

Testing the output can be done by executing preview renders, or by publishing and making assertions against the content of the published files or the output from a test web application.

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.