Insisting on a small change to our automation
Recently I performed a code review for an automated test which was being added to our suite of automation. Overall, the changes were solid except for one method being invoked. Here's the rough scenario:
- The script starts OneNote and creates a local notebook on the hard drive
- Then the script and logs into Skydrive
- The script then changes the default location for Unfiled Notes (this is what a user would do if you click File | Options | Save and Backup and Modify… the Quick Notes (or Unfiled Notes) section right at the top of that dialog).
- The script then creates a new Side Note
- Finally, and here's the step I want to focus on, the script verifies the note created in step 4 was created in the location specified in step 3. The new bit here is verifying all of this on Skydrive.
To be more specific about this last step, the test changes the section in the view to Unfiled Notes and then verifies the page was created by examining the XML we get from our importer.
Everything was fine with the test except the name of the method that actually navigated to Unfiled Notes for step 5. The name of the method was "MoveToUnfiledNotes()". Now, there is technically nothing wrong with that name. It compiles and works just fine, and even from a certain point of view - namely, a pointer keeping track of a location in a tree - this is valid. But the purpose of the test also ensures the view was updated to the correct page. And while I can think of "moving" from one page to another, I more often think of this as "navigating" to a new page.
Same thing as the web. I very seldom think I am "moving" to a new page, but I often think I am "navigating" to a new page.
So I made the comment that I thought renaming that method to "NavigateToUnfiledNotes()" would be easier to understand what the code actually does. The tester agreed with me and made her changes. This caused her to go back a bit, verify the new changes compiled - no typos, etc… - and re-trigger the test to ensure it still works. Then get a quick code review for this final change and check it in.
Now five to ten years from now I hope it will be more obvious what this method actually does in case anyone ever needs to investigate. And between now and then, hopefully more testers will see this method exists and can more easily use it in their tests.
Questions, comments, concerns and criticisms always welcome,
John