[ 
https://issues.apache.org/jira/browse/DRILL-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16468438#comment-16468438
 ] 

ASF GitHub Bot commented on DRILL-6249:
---------------------------------------

paul-rogers commented on a change in pull request #1251: DRILL-6249: Adding 
more unit testing documentation.
URL: https://github.com/apache/drill/pull/1251#discussion_r186934308
 
 

 ##########
 File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/ops/FragmentContextImpl.java
 ##########
 @@ -70,9 +69,26 @@
 import io.netty.buffer.DrillBuf;
 
 /**
- * Contextual objects required for execution of a particular fragment.
- * This is the implementation; use <tt>FragmentContext</tt>
- * in code to allow tests to use test-time implementations.
+ * <p>
+ *   This is the core Context which implements all the Context interfaces:
+ *
+ *   <ul>
+ *     <li>{@link FragmentContext}: A context provided to non-exchange 
operators.</li>
+ *     <li>{@link ExchangeFragmentContext}: A context provided to exchange 
operators.</li>
+ *     <li>{@link RootFragmentContext}: A context provided to fragment 
roots.</li>
+ *     <li>{@link ExecutorFragmentContext}: A context used by the 
Drillbit.</li>
+ *   </ul>
+ *
+ *   The interfaces above expose resources to varying degrees. They are 
ordered from most restrictive ({@link FragmentContext})
+ *   to least restrictive ({@link ExecutorFragmentContext}).
+ * </p>
+ * <p>
+ *   Since {@link FragmentContextImpl} implements all of the interfaces listed 
above, the facade pattern is used in order
+ *   to cast a {@link FragmentContextImpl} object to the desired interface 
where-ever it is needed. The facade pattern
+ *   is powerful since it allows us to easily create minimal mock context 
objects to be used in unit tests. Without
+ *   the use of interfaces and the facade pattern we would have to create a 
complete {@link FragmentContextImpl} object
+ *   to unit test any part of the code that depends on a context.
+ * </p>
 
 Review comment:
   General guideline: use the most narrow interface for the task. For example, 
"internal" operators don't need visibility to the networking functionality. 
Using the narrow interface allows unit testing without mocking.
   
   Often, the surrounding structure already has exposed the most narrow 
interface. If there are opportunities clean up older code, we can do so as 
needed to make testing easier.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add Markdown Docs for Unit Testing and Link to it in README.md
> --------------------------------------------------------------
>
>                 Key: DRILL-6249
>                 URL: https://issues.apache.org/jira/browse/DRILL-6249
>             Project: Apache Drill
>          Issue Type: Improvement
>            Reporter: Timothy Farkas
>            Assignee: Timothy Farkas
>            Priority: Major
>              Labels: ready-to-commit
>             Fix For: 1.14.0
>
>
> I am working on a presentation about how to use the unit testing utilities in 
> Drill. Instead of writing the doc and having it be lost in Google Drive 
> somewhere I am going to add a Markdown doc to the drill repo and link to it 
> in the README.md. This is appropriate since these docs will only be used by 
> developers, and the way we unit test will change as the code changes. So the 
> unit testing docs should be kept in the same repo as the code so it can be 
> updated and kept in sync with the rest of Drill.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to