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 Vue3 大型图片数据拖动排序
  • ¥15 划分vlan后不通了
  • ¥15 GDI处理通道视频时总是带有白色锯齿
  • ¥20 用雷电模拟器安装百达屋apk一直闪退
  • ¥15 算能科技20240506咨询(拒绝大模型回答)
  • ¥15 自适应 AR 模型 参数估计Matlab程序
  • ¥100 角动量包络面如何用MATLAB绘制
  • ¥15 merge函数占用内存过大
  • ¥15 使用EMD去噪处理RML2016数据集时候的原理
  • ¥15 神经网络预测均方误差很小 但是图像上看着差别太大