Rationale: Test failing on Windows with errors like this:
utils_test.go:177: Error: Could not remove file "f".
Error: remove C:\Users\appveyor\AppData\Local\Temp\utils_test_747965610:
The process cannot access the file because it is being used by another
process.
This reverts commit 6b28e38cea.
Sorry for my premature merge of Pull Request #818.
This commit expands the test coverage for the utils/utils.go module.
The utils module uses the 'github.com/spf13/jwalterweatherman' (aka jww)
package for logging. The tests take the approach of examining the log
file that is produced by this module to verify correct behaviour. This
avoids refactoring the utils module.
The log file messages written by the jww module are of the form:
<log level>: yyyy/mm/dd <string|error message>
The checkLogFile function checks each of these parts in turn except for
the date string, which is currently ignored. The final part of the log
file format can either be a single error message, or a series of
strings followed by an error message. Both the error message and the
series of strings can be empty strings.
The log file is checked using a combination of the regex package,
along with the bufio scanner type. Each test logs to its own temporary
log file. This is achieved with standard test setup and teardown
functions.
One consequence of these tests is that StopOnErr has been refactored
into call a new unexported function doStopOnErr which contains the bulk
of the original logic. This allows the same testing approach to be used
with StopOnErr as with CheckErr and cutUsageMessage, rather than look at
the exit status code of the test itself.
An unfortunate side effect of this is that the author of the tests must
now know if a log file is expected or not. If doStopOnErr determines
that an empty error message would be written to the log file then
nothing is written. In the context of the tests this means that the log
file created by the test would have no contents. Consequently there
would be nothing for the test to examine. This situation is indicated by
the boolean flag logFileExoected in the testData struct, and processed
by the logFileIsExpectedAndValid function.
Although not ideal this was deemed a reasonable compromise.
