@DerekNonGeneric I'm not sure what exactly you're looking for, but here's this:
operator is probably far too limiting to be of use past trivial comparisons such as ===, >, !==, etc. Other comparisons such as regex matches, deep object equivalence, deep property comparisons or compound assertions won't have much use for it.- Many of the mentioned properties in the ecosystem's
AssertionError implementations are framework-specific. It's clear from the proposal that this is understood, but bears repeating.
- IMO contextual information about the difference between
actual and expected is absolutely necessary for any framework to make use of an AssertionError. I believe this was the intent behind operator, but again, I think that's insufficient. For example, we could be checking that object foo and object bar are not strictly equal. operator may be sufficient for this case, but without anything else, it cannot be expressed by just actual and expected--these properties may be useless at best and misdirection at worst. So it's the responsibility of whatever is throwing the AssertionError to put enough information in there that the consumer (a test framework perhaps) can display a representation. For that reason, a free-form difference property makes sense to me. This could be structured data or just a string; it will probably be difficult if not impossible to define/standardize a structure which would represent any "assertion" which can fail. At any rate--something else is needed.
- In the case of "compound" assertions (e.g., array
foo contains object bar and has length 4), an assertion library may make both of these checks; if the first fails, it may not short-circuit the assertion. These failures would be combined into a single AssertionError then thrown. Is it possible to leverage the newish cause prop here, though it looks more like a linked list than "(potentially) multiple causes", so maybe not applicable?
("assertion libraries" above also means "assertion subsystems of testing frameworks")
@DerekNonGeneric I'm not sure what exactly you're looking for, but here's this:
operatoris probably far too limiting to be of use past trivial comparisons such as===,>,!==, etc. Other comparisons such as regex matches, deep object equivalence, deep property comparisons or compound assertions won't have much use for it.AssertionErrorimplementations are framework-specific. It's clear from the proposal that this is understood, but bears repeating.actualandexpectedis absolutely necessary for any framework to make use of anAssertionError. I believe this was the intent behindoperator, but again, I think that's insufficient. For example, we could be checking that objectfooand objectbarare not strictly equal.operatormay be sufficient for this case, but without anything else, it cannot be expressed by justactualandexpected--these properties may be useless at best and misdirection at worst. So it's the responsibility of whatever is throwing theAssertionErrorto put enough information in there that the consumer (a test framework perhaps) can display a representation. For that reason, a free-formdifferenceproperty makes sense to me. This could be structured data or just a string; it will probably be difficult if not impossible to define/standardize a structure which would represent any "assertion" which can fail. At any rate--something else is needed.foocontains objectbarand haslength4), an assertion library may make both of these checks; if the first fails, it may not short-circuit the assertion. These failures would be combined into a singleAssertionErrorthen thrown. Is it possible to leverage the newishcauseprop here, though it looks more like a linked list than "(potentially) multiple causes", so maybe not applicable?("assertion libraries" above also means "assertion subsystems of testing frameworks")