An obvious (to a tester) test case

I honestly don't remember when I ran this as an "ad hoc" test:

In my share on SkyDrive, I have a notebook with the name "Open Notebook.onetoc2." Folks that have poked around the location in which notebooks are stored have probably seen a file with this name and noticed it has the OneNote icon. It is the OneNote "table of contents" file, and that's where the "toc" in the extension comes from. The ".one" part of the extension is based on OneNote (obviously) and the "2" is a mystery even to me :) .

This file used to be hidden in OneNote 2007, but we exposed it in OneNote 2010 to make it a little easier to open a notebook the first time. The sections of a notebook are .one files and when you click one of them, you get the prompt to open the entire notebook or just that section. To avoid that prompt, we give you a file to open that says "Open notebook" which should make it more obvious what clicking the file will do. And for what it's worth, that file contains various data about the notebook, like the notebook color and section ordering.

Enough digression. The test I was running was pretty simple. I was checking to see if using that name would cause any problems in our URL parsing logic to open the a notebook. Here's what URL OneNote might use to open that notebook on a SkyDrive server:

https://hrasjc.docs.live.net/my unique id/%5e.Documents/Open%20Notebook.onetoc2/

A different example to compare if the notebook were named "Calculus101" would be

https://hrasjc.docs.live.net/my unique id/%5e.Documents/Calculus101/

In this second example, it is much more obvious that the target of the URL is a folder on the server. That first URL also happens to point to a folder, but it looks like a file name is the target. So one test I was trying was verifying that we don't interpret the "." character as having the URL target be a file (this test passed). Remember, OneNote is a folder based app, so in general we want to open the folder as a notebook.

And that leads to the second test - verify that there is no "hard coded" logic that treats the filename "Open Notebook.onetoc2" in a unique manner if it exists where we expect a folder name to be placed in a path. Again, this test passed.

The third test was related to a section name having the same name as a table of contents file. This is a little more interesting - would we actually try to open the table of contents file as a section if they both had the same name? The answer of course is no, and the reason is they don't have the same name. Section names have .one as an extension, so even though the UI shows me "open notebook.onetoc2" as the section name, the file on the server has ".one" appended to it:

https://hrasjc.docs.live.net/my unique id/%5e.Documents/Open%20Notebook.onetoc2/open%20notebook.onetoc2.one

Yet another test here was canonicalization - using the same names but with different capitalization patterns. Again, no problems.

The last thing I'll mention is that this was an "ad hoc" test. I never expected to find any bugs with this, and it was a spur of the moment "test".

You might want to debate the "realism" of this test and whether anyone would really use such specific names for sections. I can't say if anyone would and would highly doubt it. But, this is a valid value and we need to verify that all valid values actually do work. This is also one of the first tests that a tester trying to break the system would run...I remember naming many files "fdisk.*" when saving to DOS….

Questions, comments, concerns and criticisms always welcome,

John