Test hooks don't have to be special code written specifically for your tester's needs. Oftentimes, just spending a little more time and a bit more effort on your APIs is more than enough.
Think about an application like Microsoft Excel. Sitting behind all that UI is a) a powerful calculator and b) a graphing engine. If, like Excel, your application does anything resembling complicated calculations or uses anything beyond simple algorithms, I guarantee that your testers want to pound on those calculations and algorithms without having to muck with all that UI. This you may already know. However, have you asked your customers whether programmatic access would be useful to them as well? Maybe your app does almost exactly what they need but not quite. Maybe they want to harness the power of your engine to drive their line-of-business apps. This may not be something you want to enable -- public APIs mean a whole 'nuther set of test cases, future compatibility problems (users don't usually like breaking changes all that well), and various other problems. But it just might be worth it.
Besides, you need to do it for your testers anyway, right? <g/>
Here's another example. Can you imagine trying to drive Excel by pushing the mouse around and sending mouse clicks and keystrokes? It would be doable, I guess. What about driving AutoCAD this way? Sheer madness. But that's exactly what your testers need to do. Even if you have an object model or API that allows your app's innards to be manipulated directly, your testers still need to mouse and click and type their way through a whole bunch of UI tests.
If you want to make your UI testers happy, do a really good job implementing MSAA (or UIAutomation, if you're working on a Longhorn app). These technologies make UI tests much more robust, especially with respect to changes like widgets moving to a different location on the screen. And guess what? Doing a fantastic job here makes life sooo much better for people using screen readers and other assistive devices. Hmmmm...make your testers happy *plus* make your app accessible to huge numbers of people. The added pain will be worth it, I promise you.
So the next time your tester comes begging for some weird method of access to some secret inner sanctum of your app, consider whether your users could benefit from said access as well. Make your testers happy by letting them better test your app, make your customers happy by giving them more flexibility, and make your product team happy because the app has less bugs, is more stable, and so sells that many more copies. Sweetness all around!
*** Comments, questions, feedback? Want a fun job on a great team? Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need a tester and my team needs a data binding developer, program managers, and a product manager. Great coding skills required for all positions.