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
>> 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.