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 <[EMAIL PROTECTED]LID>
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 <[EMAIL PROTECTED]> wrote:

 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 strategy.
  *  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:

  *  <>

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB