hugo/utils/utils.go

61 lines
1.4 KiB
Go
Raw Normal View History

package utils
import (
"os"
"strings"
jww "github.com/spf13/jwalterweatherman"
)
func CheckErr(err error, s ...string) {
if err != nil {
if len(s) == 0 {
jww.CRITICAL.Println(err)
} else {
for _, message := range s {
jww.ERROR.Println(message)
}
jww.ERROR.Println(err)
}
}
}
func StopOnErr(err error, s ...string) {
if err != nil {
Expansion of unit tests for utils/utils.go 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.
2014-11-16 17:50:26 +00:00
doStopOnErr(err, s...)
os.Exit(-1)
}
}
Expansion of unit tests for utils/utils.go 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.
2014-11-16 17:50:26 +00:00
func doStopOnErr(err error, s ...string) {
if len(s) == 0 {
newMessage := cutUsageMessage(err.Error())
// Printing an empty string results in a error with
// no message, no bueno.
if newMessage != "" {
jww.CRITICAL.Println(newMessage)
}
} else {
for _, message := range s {
message := cutUsageMessage(message)
Expansion of unit tests for utils/utils.go 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.
2014-11-16 17:50:26 +00:00
if message != "" {
jww.CRITICAL.Println(message)
}
}
}
}
// cutUsageMessage splits the incoming string on the beginning of the usage
// message text. Anything in the first element of the returned slice, trimmed
Expansion of unit tests for utils/utils.go 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.
2014-11-16 17:50:26 +00:00
// of its Unicode defined spaces, should be returned. The 2nd element of the
// slice will have the usage message that we wish to elide.
//
// This is done because Cobra already prints Hugo's usage message; not eliding
Expansion of unit tests for utils/utils.go 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.
2014-11-16 17:50:26 +00:00
// would result in the usage output being printed twice, which leads to bug
// reports, more specifically: https://github.com/spf13/hugo/issues/374
func cutUsageMessage(s string) string {
Expansion of unit tests for utils/utils.go 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.
2014-11-16 17:50:26 +00:00
pieces := strings.Split(s, "Usage of")
return strings.TrimSpace(pieces[0])
}