Home | About | Sematext search-lucene.com search-hadoop.com
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
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hive >> mail # dev >> hi


Having said that, it might be difficult to write unit tests for operator
trees.
Might take more time initially - so, making it a constraint might slow us
down.
On 4/18/13 9:41 PM, "Brock Noland" <[EMAIL PROTECTED]> wrote:

>Hi,
>
>I like the proposal as well!
>
>On Thu, Apr 18, 2013 at 10:49 AM, Jarek Jarcec Cecho
><[EMAIL PROTECTED]>wrote:
>
>> Hi Namit,
>> I like your proposal very much and I would take it a bit further:
>>
>> >   1.  ... For any complex function, clear examples (input/output)
>>would
>> really help.
>>
>> I'm concerned that examples in the code (comments) might very quickly
>> become obsolete as it can very easily happen that someone will change
>>the
>> code without changing the example. What about using for this purpose
>>normal
>> unit tests? Developers will still be able to see the expected
>>input/output,
>> but in addition we will have automatic way how to detect (possibly
>> incompatible) changes. Please note that I'm not suggesting to abandon
>>the
>> *.q file tests, just to also include unit tests for complex methods.
>>
>
>I'd be interested in including more unit tests as well. I like the
>existing
>q file test framework but when working on code I find unit tests which can
>complete in less than a second or allows for faster iterations than
>waiting
>30 or so seconds for a q-file test to complete.
>
>Brock
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