Open boneskull opened 1 year ago
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.
“relational or equality” operators, such as <
, <=
, >
, >=
, ==
, etc. should definitely be considered for this, but there are also “identity and membership” operators like is
or in
that can also be considered for this… I think we can (and probably should) expand upon this in the proposal explainer (currently the readme file).
@DerekNonGeneric How do you mean? I guess I'm not convinced the notion of an "operator" is any finite set of values, let alone one that can be standardized. For example, what if my assertion is "the STDOUT of this command-line app, when parsed into JSON, is equal to {foo: 'bar'}
and the exit code was greater than zero?" (And yes, this can be a single assertion)
Okay, i actually didn't mean to disagree w/ you and see what you're saying now. I guess regarding that bullet point, we can't really say what that property would contain, but might want to be sure it exists?
@DerekNonGeneric I guess I'd feel better if it was optional. Assuming operator
is intended to be either a) a concise representation or b) a machine-readable representation, generating the value may be non-trivial; e.g., a hierarchical data structure or a DSL.
I mean--I guess it's a big ask for assertion libs that have composable assertions, as well as any ecosystem of plugins around those libs. Should we be considering the difficulty of adoption?
@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.AssertionError
implementations are framework-specific. It's clear from the proposal that this is understood, but bears repeating.actual
andexpected
is 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 objectfoo
and objectbar
are not strictly equal.operator
may be sufficient for this case, but without anything else, it cannot be expressed by justactual
andexpected
--these properties may be useless at best and misdirection at worst. So it's the responsibility of whatever is throwing theAssertionError
to put enough information in there that the consumer (a test framework perhaps) can display a representation. For that reason, a free-formdifference
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.foo
contains objectbar
and haslength
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 singleAssertionError
then thrown. Is it possible to leverage the newishcause
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")