dthtvk3666 2015-05-24 18:41
浏览 33
已采纳

在Go中无需睡眠即可测试异步结果

I have quite a few components in my code that have persistent go-routines that listen for events to trigger actions. Most of the time, there is no reason (outside of testing) for them to send back a notification when they have completed that action.

However, my unittests are using sleep to wait for these async tasks to complete:

// Send notification event.
mock.devices <- []sparkapi.Device{deviceA, deviceFuncs, deviceRefresh}

// Wait for go-routine to process event.
time.Sleep(time.Microsecond)

// Check that no refresh method was called.
c.Check(mock.actionArgs, check.DeepEquals, mockFunctionCall{})

That seems broken, but I haven't been able to come up with a better solution that doesn't add unreasonable overhead to non-test usage. Is there a reasonable solution that I've missed?

  • 写回答

2条回答 默认 最新

  • dow98764 2015-05-24 19:17
    关注

    Soheil Hassas Yeganeh's solution is usually a good way to go, or at least something like it. But it is a change to the API, and it can create some overhead for the caller (though not much; the caller doesn't have to pass a Done channel if the caller doesn't need it). That said, there are cases where you don't want that kind of ACK system.

    I highly recommend the testing package Gomega for that kind of problem. It's designed to work with Ginkgo, but can be used standalone. It includes excellent async support via the Consistently and Eventually matchers.

    That said, while Gomega works well with non-BDD test systems (and integrates fine into testing), it is a pretty big thing and can be a commitment. If you just want that one piece, you can write your own version of these assertions. I recommend following Gomega's approach though, which is polling rather than just a single sleep (this still sleeps; it isn't possible to fix that without redesigning your API).

    Here's how to watch for things in testing. You create a helper function like:

    http://play.golang.org/p/qpdEOsWYh0

    const iterations = 10
    const interval = time.Millisecond
    
    func Consistently(f func()) {
        for i := 0; i < iterations; i++ {
            f() // Assuming here that `f()` panics on failure
            time.Sleep(interval)
        }
    }
    
    mock.devices <- []sparkapi.Device{deviceA, deviceFuncs, deviceRefresh}
    Consistently(c.Check(mock.actionArgs, check.DeepEquals, mockFunctionCall{}))
    

    Obviously you can tweak iterations and interval to match your needs. (Gomega uses a 1 second timeout, polling every 10ms.)

    The downside of any implementation of Consistently is that whatever your timeout, you have to eat that every test run. But there's really no way around that. You have to decide how long is long enough to "not happen." When possible, it's nice to turn your test around to check for Eventually, since that can succeed faster.

    Eventually is a little more complicated, since you'll need to use recover to catch the panics until it succeeds, but it's not too bad. Something like this:

    func Eventually(f func()) {
        for i := 0; i < iterations; i++ {
            if !panics(f) {
                return
            }
            time.Sleep(interval)
        }
        panic("FAILED")
    }
    
    func panics(f func()) (success bool) {
        defer func() {
            if e := recover(); e != nil {
                success = true
            }
        }()
        f()
        return
    }
    

    Ultimately, this is just a slightly more complicated version of what you have, but it wraps the logic up into a function so it reads a bit better.

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

报告相同问题?

悬赏问题

  • ¥15 BP神经网络控制倒立摆
  • ¥20 要这个数学建模编程的代码 并且能完整允许出来结果 完整的过程和数据的结果
  • ¥15 html5+css和javascript有人可以帮吗?图片要怎么插入代码里面啊
  • ¥30 Unity接入微信SDK 无法开启摄像头
  • ¥20 有偿 写代码 要用特定的软件anaconda 里的jvpyter 用python3写
  • ¥20 cad图纸,chx-3六轴码垛机器人
  • ¥15 移动摄像头专网需要解vlan
  • ¥20 access多表提取相同字段数据并合并
  • ¥20 基于MSP430f5529的MPU6050驱动,求出欧拉角
  • ¥20 Java-Oj-桌布的计算