Testing Time (and other asyncronicities)

13 points by cgrinds


hobbified

I’m very happy about this, and I’ve already been using it while it was in the experimental stage.

At $WORK we developed a clocks library with a fake clock for this purpose (lots of people have done this, but ours was one of the few, in my opinion, to do things “right” so that the testing code can wait for quiescence without an unreliable sleep-and-pray, or sprinkling synchronization channels into the code under test). But synctest is better in pretty much every way because it gets help from the runtime. You don’t need to pass a clock all over the place, and you don’t need to worry about third-party code that doesn’t know about your clock interface; the stdlib time functions just behave the way you want them to. If you want to advance the clock, you just time.Sleep in the test driver and no real time passes. If you want to wait for quiescence, you make one Wait call and the runtime will hand control back to you when everything else in the world is blocking, which is a much better interface than we could ever offer.