News for hackers. Stuff that matters.
Re:Mocking time and testing event loops in Go by cle on Monday May 25, 2020 @09:50AM (#23301087)
It can be useful to directly unit test edge cases in critical concurrent code, because they are otherwise difficult to test deterministically. But like you said, I've also found them difficult to write and maintain (re-reading some of them months later is usually hard). The tests usually end up with 2-3x channels than the prod code, because I'm forced to inject channels into various places to control the synchronization. Sometimes though, in a critical code path, it's worth it.
Re:Mocking time and testing event loops in Go by jeffbee on Monday May 25, 2020 @12:10PM (#23302409)
Isn't this basic design for testability (TDD, if you like)? If you need some synchronization facilities to make your unit tests end cleanly, then you also need those facilities in your general APIs because applications _also_ have boundary conditions, and pretending that your application exists on an infinite timeline that neither starts nor ends is naive.
Re:Mocking time and testing event loops in Go by cle on Monday May 25, 2020 @04:39PM (#23304724)
It's not about ending cleanly, it's about behaving correctly. I would say that there's nothing "basic" about testing concurrent code--it's always been hard, no matter what language you use. Exposing your concurrency guts in the API doesn't make the intrinsic complexity go away, it just shifts it somewhere else.