So here's what I'm doing for the task library - simply updating the logging.
Since our task library does not judge a pass or fail result within its code, we have several checks that go something like this:
int originalOutlineCount = GetCountOfOutlines(activePageID);
//now need to check if the outline was added
int postActionOutlineCount = GetCountOfOutlines(activePageID);
if(originalOutlineCount + 1 != postActionOutlineCount)
TaskLibraryLog.Warning("Outline count match does not match expected");
So the code tries to add a new outline, but this action may not actually add an outline for a variety of reasons. The Warning method on the task library simply logs the comment with a warning tag so that the investigator knows that a potentially unexpected condition was hit.
If the outline is not added as expected, then a comment gets logged to a log file. If the test script fails, this can be used to help diagnose where the error may lie. But looking at this code you can see that the person investigating the script only has a potential mismatch of an expected count logged. There is no data to say what the exact condition was - we can do better.
Here's the same check routine with better logging:
TaskLibraryLog.Warning("Outline count before adding outline " + originalOutlineCount +
" Outline count after adding outline " + postActionOutlineCount +
"Expected to be equal to " originalOutlineCount+1 );
TaskLibraryLog.Comment("Outline count after adding was " + postActionOutlineCount );
I'm defining "better" here as "resulting in more actionable logs that point to all unexpected states as soon as they were detected." Other automation tasks may have a very different definition of "better," but that's OK.
Luckily, this does not change the functionality of any of the code. Since it is "just logging enhancements," it is pretty easy to understand and introduces little risk.
Questions, comment, concerns and criticisms always welcome,