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