[ https://issues.apache.org/jira/browse/DRILL-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999111#comment-15999111 ]
ASF GitHub Bot commented on DRILL-5459: --------------------------------------- Github user paul-rogers commented on a diff in the pull request: https://github.com/apache/drill/pull/823#discussion_r115103600 --- Diff: exec/java-exec/src/test/java/org/apache/drill/exec/physical/unit/PhysicalOpUnitTestBase.java --- @@ -82,6 +81,8 @@ * Look! Doesn't extend BaseTestQuery!! */ public class PhysicalOpUnitTestBase extends ExecTest { + public static long INIT_ALLOCATION = 10_000_000l; + public static long MAX_ALLOCATION = 15_000_000L; --- End diff -- Should we use the values already defined in `AbstractBase`? To do that, perhaps refactor the code from: ``` public abstract class AbstractBase implements PhysicalOperator{ ... protected long initialAllocation = 1_000_000L; protected long maxAllocation = 10_000_000_000L; ``` To: ``` public abstract class AbstractBase implements PhysicalOperator{ ... public static long INIT_ALLOCATION = 1_000_000L; public static long MAX_ALLOCATION = 10_000_000_000L; protected long initialAllocation = INIT_ALLOCATION; protected long maxAllocation = MAX_ALLOCATION; ``` Actually, I think I did that in my much-delayed external sort PR for unit testing... > Extend physical operator test framework to test mini plans consisting of > multiple operators > ------------------------------------------------------------------------------------------- > > Key: DRILL-5459 > URL: https://issues.apache.org/jira/browse/DRILL-5459 > Project: Apache Drill > Issue Type: Improvement > Components: Tools, Build & Test > Reporter: Jinfeng Ni > Assignee: Jinfeng Ni > > DRILL-4437 introduced a unit test framework to test a non-scan physical > operator. A JSON reader is implicitly used to specify the inputs to the > physical operator under test. > There are needs to extend such unit test framework for two scenarios. > 1. We need a way to test scan operator with different record readers. Drill > supports a variety of data source, and it's important to make sure every > record reader work properly according to the protocol defined. > 2. We need a way to test a so-called mini-plan (aka plan fragment) consisting > of multiple non-scan operators. > For the 2nd need, an alternative is to leverage SQL statement and query > planner. However, such approach has a direct dependency on query planner; 1) > any planner change may impact the testcase and lead to a different plan, 2) > it's not always easy job to force the planner to get a desired plan fragment > for testing. > In particular, it would be good to have a relatively easy way to specify a > mini-plan with a couple of targeted physical operators. > This JIRA is created to track the work to extend the unit test framework in > DRILL-4437. > > Related work: DRILL-5318 introduced a sub-operator test fixture, which mainly > targeted to test at sub-operator level. The framework in DRILL-4437 and the > extension would focus on operator level, or multiple operator levels, where > execution would go through RecordBatch's API call. > Same as DRILL-4437, we are going to use mockit to mock required objects such > fragment context, operator context etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)