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).
