Yea, I guess I mean I have no objections to make DirectRunner grab and run TestPipelineOptions.getOnSuccessMatcher.
But my counter-proposal is meant to read as: remove onSuccessMatcher entirely and only use waitUntilFinish and then assert on the results. I suspect the onSuccessMatcher came from the long-gone days when run() may or may not have been blocking. Today it is always "non-blocking" (but may take arbitrarily long :-) so you always waitUntilFinish(). Kenn On Wed, Jan 16, 2019 at 4:06 PM Udi Meiri <[email protected]> wrote: > Existing one? I'm not sure what you mean. There's already > TestPipelineOptions.setOnSuccessMatcher(), but that's silently ignored on > runners like DirectRunner that don't support it. > > As I see it the differences are: > onSuccessMatcher - runs after the pipeline has completed successfully, can > be applied on file output contents (e.g. FileChecksumMatcher) > PAssert - runs as part of the pipeline and is applied to PCollection > contents > > Meanwhile, I can also waitUntilFinish() and manually run the assert: > assertThat(result, new FileChecksumMatcher(EXPECTED_CHECKSUM, > filenamePrefix + "*-of-*")); > > In my case I need to verify file output contents. > > On Tue, Jan 15, 2019 at 5:56 PM Kenneth Knowles <[email protected]> wrote: > >> Since it is primarily for testing, how about just making it use the >> existing one in the pipeline options? I'm honestly a bit lost as to what >> the use case was when that was introduced, versus waiting for termination >> and running the assertion more directly. Can you enlighten me? >> >> Kenn >> >> On Tue, Jan 15, 2019 at 4:15 PM Udi Meiri <[email protected]> wrote: >> >>> Hi, >>> I want to use DirectRunner for a new IT I'm writing, since it's testing >>> I/O code that's runner agnostic. The problem is that DirectRunner doesn't >>> have a TestDataflowRunner analog, so features like OnSuccessMatcher aren't >>> available. >>> >>> Any objections to adding a TestDirectRunner class? >>> >>
