Agreed, given that most of our tests our existing tests are in .q files,
I'd prefer to see more of a "unit tests highly encouraged" policy as
opposed to "must have unit tests".
On Thu, Apr 18, 2013 at 11:17 AM, Namit Jain <[EMAIL PROTECTED]> wrote:
> Having said that, it might be difficult to write unit tests for operator
> Might take more time initially - so, making it a constraint might slow us
> On 4/18/13 9:41 PM, "Brock Noland" <[EMAIL PROTECTED]> wrote:
> >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)
> >> 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
> >> code without changing the example. What about using for this purpose
> >> unit tests? Developers will still be able to see the expected
> >> but in addition we will have automatic way how to detect (possibly
> >> incompatible) changes. Please note that I'm not suggesting to abandon
> >> *.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
> >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
> >30 or so seconds for a q-file test to complete.
Apache MRUnit - Unit testing MapReduce - http://mrunit.apache.org