Thanks Paul, I'll try to incorporate your feedback, and I'll ask you to review 
when I open a PR. By the way, would it be possible to copy your unit testing 
docs from your wiki to the docs folder in the Drill repo as well? There is a 
lot of good information that people may be missing out on since they aren't 
aware of your wiki pages.


From: Paul Rogers <>
Sent: Monday, April 9, 2018 11:30:52 PM
Subject: Re: Unit Testing Docs and [Discuss] Dev Docs location

Hi Tim,

Great idea! Anything to improve tests is a Good Thing. You have my vote.

FWIW, my notes on Drill testing are in [1]. The three "Updated" links are 
probably the most useful as they explain the test framework added over the last 
year or so. See also the "ExampleTest" class that shows how to use the new 
framework, including the schema builder, row set builder and so on.

I notice that this material is missing a good explanation about how to use the 
row set mechanisms to do operator-level tests. RowSetTest exercises the whole 
mechanism, but may not be the best example. TestResultSetLoaderProtocol is a 
bit better example of using the mechanisms to test something else. Might be 
worth creating a simple example in ExampleTest or a new ExampleOperatorTest.

I notice your material talks quite a bit about BaseTestQuery. That is a fine 
class, but the ClusterTest provides better control over boot and session/system 
options, allows faster reconfiguration of clusters, and supports using row sets 
to validate results. ClusterTest preserves the ability to use the TestBuilder 
and similar mechanisms from BaseTestQuery. The hope was that newer tests would 
use that new mechanism.


- Paul


    On Monday, April 9, 2018, 8:02:48 PM PDT, Timothy Farkas <> 

 Hi All,

I am wrapping up a unit testing doc here
 which expands on the unit testing presentation here

I'd also like to propose adding the unit testing documentation along with other 
developer docs to the Drill master repo itself as markdown documents in the 
./docs folder. There are several

advantages to doing this:

  *  The markdown docs are rendered nicely on github and in your IDE through 
the use of a markdown plugin.
  *  You can link directly to source files inside a markdown doc with this 
  *  The developer documentation is versioned and updated with the code.
  *  Developer's only have to deal with one repo for both code and 
documentation changes.

Other projects like Apache Apex, Apache Spark, Apache Kudu and others also 
utilize the markdown docs folder strategy. See here:




Reply via email to