Lists of Facts?

[sebastiang]

My tests look like

facts("parsing") do
  for (a, b) in [("1", 1), ("0", 0)] do
    @fact int(a) => b
  end
end

Which seems a bit wordy. It seems like with the strategic placement of a few ... and a map, one might be able to just say

facts("parsing", [("1", 1), ("0", 0)]) do (a, b)
  @fact int(a) => b
end

Not the most profound savings in the world, but lists of testable facts feature prominently in most test libraries I've seen. The win would come from creating automatic names for the individual facts thereby created, e.g. making an implicit context inside the facts function using show on the given tuples, making error messages nicer. This would be similar to NUnit's TestCase attribute. Instead of just a parsing set of facts, you'd know you had a parsing ("1", 1), parsing ("0", 0), etc.

Take this too far, and you might as well use QuickCheck, but I've found it a very useful approach in testing numeric code where you want to capture critical cases and boundary conditions.

I'd be happy to attempt a patch if the approach seems attractive.

[IainNZ]

So I've been moving to the test suite for JuMP to FactCheck, and I've also hit upon this awkward list/map like thing. My use case is I have a set of objects, and want to test how multiple tests work with this object, and what I have is

facts("too testing") do
for too in bar
context("applying to $foo") do
# ...
end
end
end

My preference would be to do your suggestion or something like it at the context| level, especially as we now print out context names (on master).

All PRs welcome anyway!