doubengshao8872 2017-04-25 19:59
浏览 14
已采纳

仅测试文件中的掩码包名称

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?

  • 写回答

2条回答 默认 最新

  • douqie3391 2017-04-25 21:32
    关注

    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.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论
查看更多回答(1条)

报告相同问题?

悬赏问题

  • ¥15 MATLAB运行显示错误,如何解决?
  • ¥15 c++头文件不能识别CDialog
  • ¥15 Excel发现不可读取的内容
  • ¥15 UE5#if WITH_EDITOR导致打包的功能不可用
  • ¥15 关于#stm32#的问题:CANOpen的PDO同步传输问题
  • ¥20 yolov5自定义Prune报错,如何解决?
  • ¥15 电磁场的matlab仿真
  • ¥15 mars2d在vue3中的引入问题
  • ¥50 h5唤醒支付宝并跳转至向小荷包转账界面
  • ¥15 算法题:数的划分,用记忆化DFS做WA求调