New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve support for writing custom assertions #533

Closed
jzaefferer opened this Issue Feb 13, 2014 · 4 comments

Comments

4 participants
@jzaefferer
Member

jzaefferer commented Feb 13, 2014

Currently custom assertions can't delegate to existing assertions like equal() without messing up the stack trace we display for failed assertions. Always having to use QUnit.push isn't the best API for writing custom assertions.

Ideas so far:

  • at least expose the traversal of QUnit.equiv, related to #466
  • maybe expose an API for custom assertions that fixes stack traces when delegating to other assertions?
  • or try to have the assertion wrapper/constructor keep track, so that it doesn't matter on what level you call assertions, it'll unwrap correctly
  • or try and see what happens if we simplify the stack trace handling - a few more lines might be worth removing the complexity
@leobalter

This comment has been minimized.

Show comment
Hide comment
@leobalter

leobalter Jun 24, 2014

Member

Looks like #588 fixed this, didn't?

Member

leobalter commented Jun 24, 2014

Looks like #588 fixed this, didn't?

@Krinkle

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle Jun 24, 2014

Member

@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.

Member

Krinkle commented Jun 24, 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.

@JamesMGreene

This comment has been minimized.

Show comment
Hide comment
@JamesMGreene

JamesMGreene Jul 30, 2014

Member

Perhaps a separate QUnit.compare object that houses re-usable functions that return boolean.

Not a bad idea. 👍

Member

JamesMGreene commented Jul 30, 2014

Perhaps a separate QUnit.compare object that houses re-usable functions that return boolean.

Not a bad idea. 👍

@jzaefferer

This comment has been minimized.

Show comment
Hide comment
@jzaefferer

jzaefferer May 18, 2015

Member

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 QUnit.stack(), which might be of use in custom assertions.

I don't see a need to keep this ticket open any longer.

Member

jzaefferer commented May 18, 2015

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 QUnit.stack(), which might be of use in custom assertions.

I don't see a need to keep this ticket open any longer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment