[
https://issues.apache.org/jira/browse/BEAM-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16340765#comment-16340765
]
Etienne Chauchot commented on BEAM-3159:
----------------------------------------
[~kenn] maybe. But how could you write a test such as this one (1) with only
TestPipeline and DirectRunner (only external test capabilities over the
pipeline)?
(1)
https://github.com/apache/beam/blob/87670e6f525f3a9e51f6603f072410f86be48447/sdks/java/io/elasticsearch-tests/elasticsearch-tests-common/src/test/java/org/apache/beam/sdk/io/elasticsearch/ElasticsearchIOTestCommon.java#L220
> DoFnTester should be deprecated in favor of TestPipeline
> --------------------------------------------------------
>
> Key: BEAM-3159
> URL: https://issues.apache.org/jira/browse/BEAM-3159
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-core
> Reporter: Ben Chambers
> Assignee: Kenneth Knowles
> Priority: Minor
>
> Reasons:
> 1. The logical unit within a Beam pipeline is a transform. Either a small
> transform like a ParDo or a larger composite transform. Unit tests should
> focus on these units, rather than probing specific behaviors of the
> user-defined functions.
> 2. The way that a runner interacts with a user-defined function is not
> necessarily obvious. DoFnTester allows testing non-sensical cases that
> wouldn't arise in practice, since it allows low-level interactions with the
> actual UDFs.
> Instead, we should encourage the use of TestPipeline with the direct runner.
> This allows testing a single transform (such as a ParDo running a UDF) in
> context. It also makes it easier to test things like side-inputs and multiple
> outputs, since you use the same techniques in the test as you would in a real
> pipeline, rather than requiring a whole new API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
