3 ms·

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

• sitkack 13y ago
  Could the tests be more declarative, defining properties over a space?
  • skrishnamurthi 13y ago
    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
• akkartik 13y ago
  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 http://akkartik.name/post/tracing-tests)
  • skrishnamurthi 13y ago
    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-dataflow-lang-script-debug-journal/ http://cs.brown.edu/~sk/Publications/Papers/Published/mcskr-... -- generalizes the idea in your tracing post.)
    • akkartik 13y ago
      Thanks. My post wasn't about names, I was just looking for feedback. Which I got; thanks.
• alexatkeplar 13y ago
  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/hadoop-etl/src/test/scala/utils/conversionUtilsTests.scala#L122 https://github.com/snowplow/snowplow/blob/master/3-enrich/ha...
  • skrishnamurthi 13y ago
    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.
    • alexatkeplar 13y ago
      If you can up with a cleaner syntax for test data tables that would be awesome, thanks Shriram.