Automation cleanup continues.
Last week I needed to set a registry key before an automated test ran. The test I was trying to automate was "remove a page title that has text in it". In OneNote 2007, click Format | Show Page Title. In OneNote 2010, click View | Hide Page Title. If you have text in the title, you should get this prompt:
This is a nice little alert to let us know that by removing the title bar at the top of the page, the contents of it will be deleted. It also gives a checkbox to suppress showing this dialog again. If you select that checkbox, this registry key is created:
Just substitute "12.0" for "14.0" to see the OneNote 2007 key. We can get the version of OneNote from our task library if you remember this.
Anyway, since our automation is UI-less, I want to avoid having to deal with that dialog during the test. So the easy solution is to set the registry key before the test runs. When I first updated the test, I had exported the registry key and simply merged the registry file into the machine before the test executed. This worked well, but failed the peer code review needed to check in.
The code reviewer suggested I simply write the registry key from my script before removing the page title. This is fairly trivial to do - I already know the key, the OneNote version and the value to write. The code to do this is published all over MSDN and is simple. We had a little debate about this (I did not want to re-write working code) but we eventually decided that the long term ability of the test to not need to be updated for future versions was a best practice we wanted to adopt.
While it is pretty easy to update a single value in one registry file when we start working on a new version of OneNote, this task can get a bit more complicated with a larger number of files. And if they are not all stored in one location, the complications multiply. So let's keep it simple, create the registry key within the test and then we are done. Not earth shattering, but it is a small improvement that will lower the amount of time needed for automation cleanup tasks in the future.
Questions, comments, criticisms and concerns always welcome,