You can get around this by making a loop around the “test” instead of the “assert” and putting the test value into the test name, but I generally don’t bother with the loop because of reasons stated above.
kanishka
dimitarvp
Weird how nobody did tests to get best from both worlds:
for n <- [1, 2, 4, 7, 8] do
n = Macro.escape(n)
test "fizz_buzz(#{n}) returns the input number as a string" do
n = unquote(n)
assert fizz_buzz(n) == "#{n}"
end
end
Basically have your code generate tests. And if one fails you’ll have an exact test title + assert diff showing exactly what’s wrong.
I do such tests any chance I get because it helps cover several potentially-gotcha values.
But if we’re going into that territory then I’ll side with @hauleth – when you need to prove properties of your code then property testing is what you want. And it’s not an overkill at all, you use it 4-5 times and you get used to it. I have never spent more than 20-30 minutes adding property tests once I learned stream_data (which admittedly took me a weekend of tinkering, though it was well worth it).
2
jarmo
I always prefer explicit tests. Yes, they are more tedious to write, but much easier to understand when they start to fail.
Also, if trying to keep tests as DRY as production code then at one point they might get so complex that they need their own tests.
2