[
https://issues.apache.org/jira/browse/DRILL-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16468447#comment-16468447
]
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_r186938309
##########
File path: docs/dev/Testing.md
##########
@@ -2,27 +2,108 @@
Drill makes extensive use of [JUnit](http://junit.org/junit4/) and other
libraries for testing. This page provides pointers to the information you need
to work with Drill tests. We don't repeat that information; you will want to
follow the links and read the original material to get a complete understanding
of the libraries that Drill uses.
-Caveat: information here about Drill is "reverse engineered" from the code;
this page has not yet had the benefit of insight from the developers who
created Drill's test structure.
-
-# Topics
-
-"Classic" Drill testing techniques
+# Writing Tests
Review comment:
I've not read the full, original material. This stuff is really quite good.
The one suggestion I'd make is to provide some overall design hints. For
example, when should someone use `ClusterFixture` to create an integration test?
When should they use `OperatorFixture` to do a lower-level test?
The answer I followed was that any detailed testing of an operator or other
internal mechanism can only be done at the unit level. (All the `RowSet`,
`ExternalSort` and `ResultSetLoader` stuff are examples.) This may mean
designing the code so it can be tested by controlling dependencies.
Use the `RowSet` mechanism to set up a complete set of input data sets:
types, cardinalities, nesting levels: whatever is relevant. As shown in the
sort tests, clever coding can automate much of this stuff. There is even a
function to generate data for every data type given an int so that can populate
types with data that is easy to compare.
Then, once the detailed internal tests are done, use integration tests to
ensure the whole system works.
At present, for most readers, integration tests are really the only approach
because of the dependencies that Scan has. The in-flight work in the "batch
sizing" stuff solves this problem, but only for newer readers designed to use
that framework.
The general rule is: test as close to your code as possible, refactoring and
breaking dependencies where needed to accomplish this.
On the other hand, if the test is more of a SQL or planner-level concept,
then testing at the query level might be fine.
----------------------------------------------------------------
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:
[email protected]
> 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)
