Join GitHub today
Improve support for writing custom assertions #533
Currently custom assertions can't delegate to existing assertions like
Ideas so far:
This was referenced
May 30, 2014
@leobalter No, it does not. We still rely on the stacktrace depth and there is no good way to re-use the logic of another assertion method. And that's basically the only obstacle, #588 didn't get us closer or farther away from that.
I'd actually support dropping the stacktrace hacking. Let's just keep assertion path included in the stacktrace. We could still trim the path between the Test class and the reporter (if we want to), but I don't see why we'd filter out the calls between the test suite and the assertion method(s). If anything, they could be useful.
At this point we'd have the basics of re-using assertion methods. I mean, if one doesn't care about the stracktrace one could already call another assertion method.
However there's some issues still that make this a bit ugly. Such as what to display in actual/expected and whether there is a sensible diff to perform.
One thing we could do is separate the meta data, display handling, and comparison. This can quickly end up with a large pile of over-engineered classes though. But a general direction to consider.
Perhaps a separate QUnit.compare object that houses re-usable functions that return boolean.
Based on my own usage and from reported issues and implementations of custom assertions, I don't see a practical need for this.
Regarding stack traces, we're now exposing
I don't see a need to keep this ticket open any longer.