One of the problems with hard coded strings

Just about a year ago, I wrote about a problem our automation scripts had with hard coded strings. In that case, the version number of OneNote was a problem. We recently had a similar problem but this time based on a string used in our namespace for our COM API. If you have written powertoys or other addins, you have probably referenced "https://schemas.microsoft.com/office/onenote/2010/onenote" or "https://schemas.microsoft.com/office/onenote/2007/onenote". Any time we change our schema, we have to update this string.

Ideally, we would have one instance of this string that was built dynamically. This way, when the development team changes the version number, our string would update itself at the same time. This way we would never need to update our automation that needs to use the newest schema.

That's actually a bit of work, and would not work in cases in which we wanted to use an older schema against a newer version of OneNote. This is the same state you are in if you use one of the OneNote 2007 powertoys with OneNote 2010. They will work if you are still using OneNote 2007 sections (since that is the schema the powertoy can use). Since this is a valid configuration, we need to test it, and we would not want to convert all of our tests to use only the newest schema. We need to have both schemas tested, so we have to have a method to keep the older strings (namespaces) around.

So another method would be to have a global string for each supported namespace - something like

string ON2007NameSpace = "https://schemas.microsoft.com/office/onenote/2007/onenote" and

string ON2010NameSpace = "https://schemas.microsoft.com/office/onenote/2010/onenote" and

string ONCurrentNameSpace = "https://schemas.microsoft.com/office/onenote/" + some routine to get the current string + "/onenote"

This would be great - automation writers could just use whichever string made sense for the test. Or use them all and repeat the test once for each string if that needed to be tested.

But the problem I faced was a little different. I had to dig through a set of our test files for some of the tools we use to see where this string existed. In some cases, it was near the top of the source file. In other cases, the string was duplicated in several locations in the file, so I had to make the same change in several different locations.

This got our test code up and running, but the code can definitely be improved (why duplicate a string in several different locations?). I did not want to refactor the code since I did not want to take a chance of breaking our test tools - the goal here was to get the tool up and running as quickly as possible. We'll wait until we have more time to refactor this code and make it more resilient in the future.

There's a hidden lesson here - when you need to solve problem 1 (getting the tool working after a string change quickly so you don't lose any coverage), resist the urge to tackle problems 2 (making this string exist in only one location instead of being scattered about) and problem 3 (coming up with the routine to build that string on demand - this sounds fairly easy, but "fairly easy" has a way of causing all kinds of delays). Plan to get that work done when time constraints are not a concern.

Questions, comments, concerns and criticisms always welcome,

John