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 PointNet++的onnx模型只能使用一次
  • ¥20 西南科技大学数字信号处理
  • ¥15 有两个非常“自以为是”烦人的问题急期待大家解决!
  • ¥30 STM32 INMP441无法读取数据
  • ¥15 R语言绘制密度图,一个密度曲线内fill不同颜色如何实现
  • ¥100 求汇川机器人IRCB300控制器和示教器同版本升级固件文件升级包
  • ¥15 用visualstudio2022创建vue项目后无法启动
  • ¥15 x趋于0时tanx-sinx极限可以拆开算吗
  • ¥500 把面具戴到人脸上,请大家贡献智慧,别用大模型回答,大模型的答案没啥用
  • ¥15 任意一个散点图自己下载其js脚本文件并做成独立的案例页面,不要作在线的,要离线状态。