On Sun, Nov 10, 2013 at 10:55:16AM +0100, Tarek Ziadé wrote:
I've read about Pyret on hackernews: http://www.pyret.org/
Looks very interesting.
and found the 'where' statement very compeling. Functions can end with a where that contains small unit tests.
From the documentation example:
fun sum(l): cases(List) l: | empty => 0 | link(first, rest) => first + sum(rest) end where: sum() is 0 sum([1, 2, 3]) is 6 end
Sadly, I really dislike that. To me, "where" has absolutely nothing to do with testing. I see that Pyret also includes a "check" keyword which also does testing. That seems like a more sensible keyword.
I would prefer to see some variation on Nick Coglan's ideas about a "where" keyword for local scoping of temporary variables. This is an idea that's been floating around for a long time:
Quite frankly, although I believe that tests are of vital importance, I remain to be convinced whether they should be "a first-class citizen of the language" as you put it. In my experience, for every line of code you write, you'll probably need anything from 3-10 lines of test code. I don't think that much test code belongs in the same module as the function itself -- that's an invitation to have people stint on their testing. Look at the example given -- do you really feel that this is sufficient testing for the sum() function?
I don't object to having a few, simple, fast tests in the main module, but for "real" unit testing and regression testing, they ought to be moved out into a separate file. Tests are often, usually, boring code which just distracts from the code you care about. I would hate to see it become common to have something like this:
# 20 lines of code
# 170 lines of tests
But in any case, I think it is far too early to be thinking about stealing an idea from Pyret. The language isn't even stable yet, let alone at the stage where this idea has proven itself in the real world. Pyret and the where clause is still experimental.
It's quite similar to the doctests ideas I guess - but not intended to be documentation like them.
I ended up disliking docttests because of this doc+test duality by the way: it often ends up as a not so good documentation and not so good tests.
In my experience, people who write poor doctests would write equally poor unit tests, or "where" tests if Python had this feature.
Anyways, having a dedicated keyword to append after a function some tests as part of the language has benefits imho:
I don't understand this comment. In what way are unit tests from the unittest module, or doctests, not "real" unit tests?