My biggest gripe with these is the inability to name the tests. What exactly is a unittest block testing for? You need to rely on comments or read the test code where none exists. Doesn't seem like Pyret fixed that issue.

Everything is fixable in a new language (-:. Say more!

One of my favorite things about tests is that they let me read a new codebase more interactively. If I don't understand why a function is built like this and not that I can rewrite it the new way, run the tests. Without names I'd know I broke something, but with a good name I'll often realize why that something matters in the big picture.

(I think about tests a lot: http://akkartik.name/post/tracing-tests)

I understand your point. One thing I pushed for initially, dropped because we had bigger fish to fry, and will revisit later, is the idea that you should be able to name everything: not just tests but an individual variant in your data definition, lines of code, etc. And this should be intrinsic to the language.

That said, I couldn't see what your post had to do with this concept; if I've missed something, please explain. (As an aside, I believe this -- http://cs.brown.edu/~sk/Publications/Papers/Published/mcskr-... -- generalizes the idea in your tracing post.)

Thanks. My post wasn't about names, I was just looking for feedback. Which I got; thanks.

I would like it if the `where` tests supported DataTables for a slightly more declarative style. Here's an example from Scala/Specs2: https://github.com/snowplow/snowplow/blob/master/3-enrich/ha...

The fact that they don't now doesn't mean they can't in future!

One of the advantages of having a separate block for tests is we can do things in that block that won't necessarily pervade the whole language where it might not make sense (which we already do: eg, the keywords "is" and "satisfies"). We've all done some sort of "here's a list of tuples, now map the prefix of this as arguments and the suffix as the expected value over this function", so it is something on our mind.

But I've struggled a bit to find a good way of writing it. We've written a few things where it looked truly "naked" to have these tuples without the surrounding function call. So it's as much a matter of syntax design as anything else.

I must say that the code on that page does not look like something I want to copy; it looks like a good compromise, but with emphasis on both words. We don't need to compromise.

If you can up with a cleaner syntax for test data tables that would be awesome, thanks Shriram.

Could the tests be more declarative, defining properties over a space?

Absolutely! Pyret's test section has a "satisfies" keyword for property tests. E.g.:

  check:
    insert(a-value, a-balanced-tree) satisfies is-balanced
  end

or even

  check:
    tree-examples = [ ... ]
    values = [ ... ]
    for each2(t in tree-examples, v in values):
      insert(t, v) satisfies is-rbtree
    end
  end

That's an advantage in my book... it is testing the unit (function in this case) and it is testing all the corner cases... do you have a name for each of them? Description through comments is much more suitable IMHO.

I really hate some things about the Rspec/Cucumber suite, but providing a way to output what the tests are testing as they run is a major advantage. I like being able to run my test suite and see "it does what it's supposed to do in this case" output.

At a glance, the Pyret default appears to be that tests run silently. How do I know the right tests were run?

Corner cases? Tests test the behaviour of the function. Functions, depending on their complexity, have a range of behaviour. And yes, you should (usually) be able to come up with a name for it. As a bonus, you'll get immediately an idea of what broke upon test failure.