Hey all - I write and maintain the ginkgo testing framework and am fielding inquiries about supporting synctest in Ginkgo. I'd love to - but there's an impedance mismatch between the synctest interface and Ginkgo's spec model.
Is there appetite for exploring this with me?
My first instinct was to hook into synctest.Test(t *testing.T, f func(*testing.T)) but Ginkgo's specs aren't a single function - they're a sequence of closures (e.g. BeforeEach() -> It() -> AfterEach()) that need to inhabit the same bubble, while Ginkgo's own timing and interrupt machinery needs to remain outside that bubble. Moreover, I can't inject and control my own instrumented implementation of T as Test takes a concrete *testing.T type and passes in a modified *testing.T to f.
Ideally, I'd have a lower-level API for creating and managing bubbles directly — something that lets me create a bubble and attach goroutines to it as each spec node runs, all without capturing Ginkgo's own time calls in the process. Looking at internal/synctest, it seems like it exposes roughly this kind of control. I'd love to explore whether there's openness to making a minimal version of that interface public, or augmenting testing/synctest to give callers finer-grained control over bubble lifecycle.
Is there appetite for exploring this? Happy to collaborate on what the right API shape might look like.
Hey all - I write and maintain the ginkgo testing framework and am fielding inquiries about supporting
synctestin Ginkgo. I'd love to - but there's an impedance mismatch between thesynctestinterface and Ginkgo's spec model.Is there appetite for exploring this with me?
My first instinct was to hook into
synctest.Test(t *testing.T, f func(*testing.T))but Ginkgo's specs aren't a single function - they're a sequence of closures (e.g.BeforeEach() -> It() -> AfterEach()) that need to inhabit the same bubble, while Ginkgo's own timing and interrupt machinery needs to remain outside that bubble. Moreover, I can't inject and control my own instrumented implementation ofTasTesttakes a concrete*testing.Ttype and passes in a modified*testing.Ttof.Ideally, I'd have a lower-level API for creating and managing bubbles directly — something that lets me create a bubble and attach goroutines to it as each spec node runs, all without capturing Ginkgo's own
timecalls in the process. Looking atinternal/synctest, it seems like it exposes roughly this kind of control. I'd love to explore whether there's openness to making a minimal version of that interface public, or augmentingtesting/synctestto give callers finer-grained control over bubble lifecycle.Is there appetite for exploring this? Happy to collaborate on what the right API shape might look like.