Hacker News Reader

Comment by yummyfajitas | Hacker News Reader

    def publish!(current_time_TEST_USE_ONLY = Time::now)
        self.update published_at: current_time_TEST_USE_ONLY
    end

Another way to do it (what I do) is simply run the test, and compare obj.published_at to Time::now. If they differ by more than 100ms, something has gone terribly wrong (if you use Ruby, maybe replace 100ms with 1s).

View on HN

> If they differ by more than 100ms

Please don't do this. It'll work fine for you, but if your tests ever get integrated into a larger system, then tests may start breaking randomly. I might be running tests concurrently, for example. On a virtual machine whose host is a bit more heavily loaded than normal. Running a large test suite is one situation where I don't care about interactivity and can just go away and come back later. Except that with a test that makes assumptions about running time, I can't. And this problem has actually happened to me, so isn't just hypothetical.

I can't count the number of times I've had to re-kick a build because a timing-dependent test like that failed (busy build server, inopportunely timed gc, etc). One of my top programming annoyances.

the perfect recipe for a flaky test!

If you have to do this, you could check that the published time was >= the time at which you started the test, and <= the time at which you are doing the check.

Reply on news.ycombinator.com