My only concern is that in the example, you first need to declare all the inputs, then the pipeline to be tested, then all the outputs. This can lead to tests that are hard to follow, since what you're really testing is an interleaving more like "When these inputs arrive, I get this output. Then when this happens, I get that output. Etc.".
What if instea of returning a PTransform<PBegin, PCollection<Long>> we had a "TestSource". so we did something like: TestPipeline p = TestPipeline.create(); TestSource source = p.testSource(); // Set up pipeline reading from source. PCollection<Long> sum = ...; BeamAssert sumAssert = BeamAssert.sum(); // Test for the Speculative Pane source.addElements(...); source.advanceWatermark(...); sumAssert.thatWindowPane(...); // Test for the On Time Pane source.addElements(...) source.advanceWatermark(...); sumAssert.thatWindowPane(...); etc. We could also allow TestSource to work with multiple input pipelines like this: TestSource<Integer> intSource = p.testSource(new TypeDescriptor<Integer>()); TestSource<Long> longSource = p.testSource(new TypeDescriptor<Long>()); ... intSource.addElements(...); longSource.addElements(...); etc. On Fri, Mar 25, 2016 at 4:08 PM Thomas Groh <tg...@google.com.invalid> wrote: > Hey everyone; > > I'd still be happy to get feedback. I'm going to start working on this > early next week > > Thanks, > > Thomas > > On Mon, Mar 21, 2016 at 5:38 PM, Thomas Groh <tg...@google.com> wrote: > > > Hey everyone, > > > > I've been working on a proposal to expand the capabilities of our testing > > API, mostly around writing deterministic tests for pipelines that have > > interesting triggering behavior, especially speculative and late > triggers. > > > > I've shared a doc here > > < > https://docs.google.com/document/d/1fZUUbG2LxBtqCVabQshldXIhkMcXepsbv2vuuny8Ix4/edit?usp=sharing> > containing > > the proposal and some examples, with world comment access + explicit > > committer edit access. I'd welcome any feedback you all have. > > > > Thanks, > > > > Thomas > > >
