On Friday, 26 January 2018 at 13:05:26 UTC, Jonathan M Davis
wrote:
Why are you using strings for any of this? Printing out the
expression is kind of pointless. If you have the file and line
number (which an AssertError will give you), then you know
where the failure is, and you can see the expression. All of
this extra machinery is just going to increase your compile
times for no benefit. So, what you're doing here is objectively
worse than just using assertions.
There might be some value if you had something like
assertEqual(lhs, rhs);
and then on failure, you printed the values that were being
compared, since that's not necessarily information that's in
the code, but the expressions themselves _are_ already in the
code, so printing them out doesn't help any.
That's actually what I have:
```
// Usage:
// mixin(requireEq!q{expected, actual});
// Checks whether the `actual` value is equal to `reauired`.
string requireEq(string expr)(string file = __FILE__, int line =
__LINE__)
{
import std.array, std.conv, std.string;
auto parts = expr.split(",");
return q{
{
bool equal = false;
static if (__traits(isFloating, $expected) ||
__traits(isFloating, $actual)) {
import std.math;
equal = approxEqual($expected, $actual);
} else {
equal = $expected == $actual;
}
if (!equal) {
import std.stdio, std.conv;
writeln("Test failed @", `$file`, ":", $line,
"\n",
" Expected `", `$actual`, "` to be `",
to!string($expected), "`, but got `",
to!string($actual), "`\n");
}
}
}.replace("$expected", parts[0].strip())
.replace("$actual", parts[1].strip())
.replace("$file", file)
.replace("$line", to!string(line));
}
```
The sample code I posted before, was way much simpler than this.
But even if you have helper functions that take the values
separately so that they can be printed, in my experience, the
extra template instantiations required to use helper functions
like that everywhere in unit tests increases the compilation
times (and memory required) enough that it's not worth it,
especially when you consider that once the tests are passing,
all of that extra machinery does you no good whatsoever.
Ultimately, it just costs less to temporarily make an
adjustment to the test and rerun it if you need more
information.
I won't argue against asserts. I agree with your point: they are
fine for simple cases, and they are definitely faster to compile
than any other framework.
My ultimate goal is to implement a BDD framework, so that I could
write tests in the most productive (for myself) way. I'm not
aiming for a production-ready quality, a toy framework that suits
my needs would be just fine.
If you don't think that simply using assertions for unit tests
is good enough, then I'd suggest that you look at
https://code.dlang.org/packages/unit-threaded
Thanks, I'll look at it.
Also, I have a vague idea that aliases may be the key to the
desired functionality.
BR
--
Oleksii
