[
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)
