It's tempting to see Tridion templating as an exercise in object-oriented programming, in which idiom the most obvious automated test is a unit-test. It's often better to see it as a data transformation. Then the most obvious testing idiom is to set up a known state in the package before the template executes, and afterwards to make assertions about the resulting state.
With this in mind, some of us created a framework that supports this kind of testing. You can find it here.
Even the T-Cubed framework is probably better suited to testing Component Template building blocks. For Page Templates, a good approach is to create test pages and assert against the output from the render. You can call Render directly from the API, or publish the page and test it using a web testing framework. If you use component presentations with known, recognisable output, it helps to keep your page tests simple.