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.