Frustrating automation investigations

So I have an automated test which checks our ability to insert PDF files into OneNote, and it fails, and that has been bothering me. This test runs for OneNote 2007 and higher and I just got a report that it failed with OneNote 2007. We have not made any changes to that product recently, so I was curious why it failed. One of the really great pieces of functionality our automation system has is the ability to get a screen shot at the point my test detects a failure - the theory here is that " a picture is worth a thousand words." In this case, that was exactly true.

So when my test tries to print the PDF, Acrobat Reader gets touched. When that happens, it checks to see if there is a newer version. Since this particular machine has version 7 of the Reader, it is far out of date.

And the modal dialog it opens causes my test to fail. This is yet another reason I am not a believer in UI based automation - I'm trying to test a OneNote codepath here, but a modal dialog (from another application, no less) is not only causing my test to fail, but is actually blocking my test from being run. If I could suppress that UI from Adobe, I think I would have a much more stable test which could focus on the OneNote code and not worry about this other UI.

So I'll enter a bug for the lab to globally update all Adobe installs for now. And retrigger my test once that is done to verify OneNote is still working as expected.

Questions, comments, concerns and criticisms always welcome,
John