[
https://issues.apache.org/jira/browse/BEAM-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517821#comment-15517821
]
Kenneth Knowles commented on BEAM-672:
--------------------------------------
An important use case to consider (we talked offline about this) is that an IO
connector will have some set of testing options, and a runner with have some
set of testing options (possibly coming from the environment) and they both
need to be applied.
I have heard it suggested many times that TestPipeline should be a JUnit @Rule
so it cannot be used incorrectly. This might address what you are talking about
in another way that is pretty handy.
IMO the generally useful functionality of "make run() / count the PAsserts"
should be kept orthogonal from reading options from an environment variable.
> Figure out TestPipeline.create(PipelineOptions) /
> TestPipeline.fromOptions(PipelineOptions) story
> -------------------------------------------------------------------------------------------------
>
> Key: BEAM-672
> URL: https://issues.apache.org/jira/browse/BEAM-672
> Project: Beam
> Issue Type: Improvement
> Components: sdk-java-core
> Reporter: Luke Cwik
> Priority: Minor
> Labels: test
>
> TestPipeline integrates with the integration testing environment and relies
> heavily on being able to be configured by the environment and executed on
> many runners.
> Tests which rely on mutating PipelineOptions before creating the TestPipeline
> easily can get the integration wrong by creating PipelineOptions from
> PipelineOptionsFactory and then calling either TestPipeline.create(options)
> or TestPipeline.fromOptions(options), thus ignoring any integration
> environment pipeline options specified.
> We should fix the exposed methods on TestPipeline to prevent users from
> making this simple mistake.
> One suggestion is to create a TestPipeline builder which will give access to
> a mutable PipelineOptions which the user can edit before calling build()
> creating a TestPipeline.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
