Gerbrand posted a nice summary about the pros and cons of Tridion .NET Templating on the blog of Tridion expert Albert te Boekhorst. One of the pro's is the possibility to (partially) unit test the Template Building Blocks. On the other hand testing still has room for improvement because of the low extensibility I'd like to talk a bit more about the (im)possibilities of unit testing your Template Building Block.
The Good
.Net Templating leaves you free to write your own C# Template Building Block by implementing the ITemplate interface. This makes it also possible to do unit testing.
The Bad
Tridion objects are hard to fake, because of low extensibility and lack of 'hooks', and instantiate, because of private constructors or the need for an active Tridion Session.
The Ugly
I have tried to write an abstraction layer for some of the Tridion objects to be able to test my code, but this led to a lot of overhead and utter frustration.
So what to do?
It's a PITA to test code that uses Tridion Objects. Only unit test the parts of your code where you don't use Tridion, so keep this in mind while designing your code. Seperate the logic that does not need Tridion directly (f.e. performing XML transformations or regular expressions on content) so they can be unit tested.
If you you want to have integration tests I would suggest to create a new Tridion publication with test data which covers the different transformation paths and verify the output (f.e. by reading it from the database and comparing it to existing xml / text files).
5 comments:
Hi Jeroen,
Very interesting post. I have been having the idea of using TDD and being able to test template code for a long time now.
Unfortunately, as you say, Tridion doesnt support this kind of approach very well or not at all. Getting a session active requires you to be working on the CM server and the Tridion objects are very difficult to mock. However, mocking the ItemFields collection of a component and ComponentPresentation collection of a page shouldnt be too much work because the former is mainly based on XML and the latter is mostly just a few references.
Hopefully we will see more support for this in the future. I would say this makes a great idea to submit on ideas.sdltridion.com
Thanks, Yoav.
Hi Yoav,
I've got an extra blog post planned with some code examples of why some things can't / are hard to be faked (I use the name faking in stead of mocking after seeing some of Roy Osherove's screencasts).
I'll submit testability as an idea an post the link on my blog. I'll expect your vote :-)
You got it!
Some good points Jeroen. Definitely you don't want to be too "purist" about unit testing when working with Tridion. Lots of people just say it's not possible and give up. Realistically, what you want is automated testing, rather than the kind of unit testing that you might do in a pure OO environment.
There's a lot of good work to be done. Glad to see that it's not just me!! :-)
IIRC the key methods to being able to mock an engine are public and virtual in Tridion's Engine implementation.
So even though you cannot implement an IEngine interface, you can derive a MockEngine from the existing engine and override some key methods and properties to for example read their data from a directory of XML files.
Post a Comment