Mask package name in test file only - unit-testing

Question

In pursuit of 100% unit test coverage, we have several lines we're trying to test in one of our functions. The relevant function calls out to the runtime package:
// functionName returns a string representing the function name of the function n stack frames above the caller.
// if n = 0, the name of the function calling functionName() will be returned.
func functionName(n int) string {
pc, _, _, ok := runtime.Caller(n + 1)
if !ok {
return "unknown function"
}
me := runtime.FuncForPC(pc)
if me == nil {
return "unknown function"
}
split := strings.Split(me.Name(), ".")
if len(split) == 0 {
return "unknown function"
}
return split[len(split)-1]
}
Specifically, the 3 if statements and their return values are currently untested, because the runtime functions don't appear to be easily manipulated to return the values we want. Our standard response in these cases is to mock out the items in question, but these calls are to package-level functions (rather than methods of an interface) within the runtime package itself.
My first thought was to mock out the runtime token itself by using a structure with Caller() and FuncForPC() methods, assigned to a variable named "runtime" in the test files (so it wouldn't affect the production code flow, since test files are omitted during normal builds). However, this triggers a build error about "runtime" being redeclared within the (global) block.
I know this would be possible if the "runtime" variable were declare in a non-global scope (example masking fmt), but I can't find an elegant way to do so such that it gets masked within the tests, but not within the production code itself. The only way I've thought of is by altering the source of the production code to declare such a variable and replacing it's value in the tests, but this is far from ideal, since it complicates the production code purely for the purposes of testing.
Any ideas?

Answer 1

One solution is to declare variables of those functions you want to mock.
var runtimeCaller = runtime.Caller
var runtimeFuncForPC = runtime.FuncForPC
func functionName(n int) string {
pc, _, _, ok := runtimeCaller(n + 1)
if !ok {
return "unknown function"
}
me := runtimeFuncForPC(pc)
if me == nil {
return "unknown function"
}
split := strings.Split(me.Name(), ".")
if len(split) == 0 {
return "unknown function"
}
return split[len(split)-1]
}
Or if you prefer the dot notation...
var _runtime = struct{
Caller func(skip int) (pc uintptr, file string, line int, ok bool)
FuncForPC func(pc uintptr) *runtime.Func
}{runtime.Caller, runtime.FuncForPC}
func functionName(n int) string {
pc, _, _, ok := _runtime.Caller(n + 1)
if !ok {
return "unknown function"
}
me := _runtime.FuncForPC(pc)
if me == nil {
return "unknown function"
}
split := strings.Split(me.Name(), ".")
if len(split) == 0 {
return "unknown function"
}
return split[len(split)-1]
}
And in your tests, before running functionName, you can set the variables/fields to mock implementations. And if other tests may cause the functionName to be called beware of concurrent access... I don't think there is much else you can do without changing the existing code significantly.

Answer 2

On the reliability of programs. Edsger W. Dijkstra
The first moral of the story is that program testing can be used very
effectively to show the presence of bugs but never to show their
absence.
Let's read your code. Go type int is a 32- or 64-bit signed integer. Therefore, consider,
funcname.go:
package main
import (
"fmt"
"runtime"
"strings"
)
// functionName returns a string representing the function name of the function n stack frames above the caller.
// if n = 0, the name of the function calling functionName() will be returned.
func functionName(n int) string {
pc, _, _, ok := runtime.Caller(n + 1)
if !ok {
return "unknown function"
}
me := runtime.FuncForPC(pc)
if me == nil {
return "unknown function"
}
split := strings.Split(me.Name(), ".")
if len(split) == 0 {
return "unknown function"
}
return split[len(split)-1]
}
func main() {
for skip := -4; skip <= 4; skip++ {
fn := functionName(skip)
fmt.Println(functionName(0), skip, fn)
}
const (
sizeInt = 32 << (^uint(0) >> 63)
maxInt = 1<<(sizeInt-1) - 1
minInt = -1 << (sizeInt - 1)
)
for _, skip := range []int{minInt, maxInt} {
fn := functionName(skip)
fmt.Println(functionName(0), skip, fn)
}
}
Output:
$ go run funcname.go
main -4 skipPleaseUseCallersFrames
main -3 skipPleaseUseCallersFrames
main -2 skipPleaseUseCallersFrames
main -1 functionName
main 0 main
main 1 main
main 2 goexit
main 3 unknown function
main 4 unknown function
main -9223372036854775808 skipPleaseUseCallersFrames
main 9223372036854775807 skipPleaseUseCallersFrames
$
It looks like a bug in functionName to me. What did your coverage testing say about this?
Reading your code there appears to be no reliable way to detect the return of an error value. One way would be to return an empty string. If you want to use a special value such as "unknown function" then provide a value to check against. For example,
const functionUnknown = "unknown function"
func functionName(n int) string {
pc, file, line, ok := runtime.Caller(n + 1)
if !ok {
return functionUnknown
}
// . . .
}
func main() {
fn := functionName(0)
if fn == functionUnknown {
// handle error
}
}
What did your coverage testing say about this?