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" <br...@cloudera.com> wrote: >Hi, > >I like the proposal as well! > >On Thu, Apr 18, 2013 at 10:49 AM, Jarek Jarcec Cecho ><jar...@apache.org>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
