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 <nj...@fb.com> wrote: > 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 > > -- Apache MRUnit - Unit testing MapReduce - http://mrunit.apache.org
