Handle `AssertionError` as a failure, not an error, for compat with other libraries

[LeaVerou]

As @Zearin pointed out in #111, this prevents users from utilizing other assertion libraries.
We should handle AssertionError differently, and show it as a failure rather than an error. All the info we need (actual, expected, etc) are already properties on the error object (e.g. see https://nodejs.org/api/assert.html#class-assertassertionerror ), so that should be pretty easy to do.

[Zearin]

@LeaVerou Do you think it might be worth considering rewriting hTest to use AssertionError internally by default?

Instead of “adding on” a compatibility layer, it would mean that the basis of pass/fail would be whether an AssertionError was thrown. That would make hTest internally consistent regardless of whether the user is using hTest’s built-in assertion functions or any other assertion lib they want.

(hTest is not at v1.x yet, so this is not a breaking change! 🤓)

[LeaVerou]

@LeaVerou Do you think it might be worth considering rewriting hTest to use AssertionError internally by default?

It is unclear to me whether there's a benefit to this for hTest (which doesn't mean one doesn't exist, it could also mean I'm missing something). Other testing libraries bunch up all their tests in a single callback, so they need the stack trace to figure out what test failed. hTest doesn't have this issue, and it's a bit of an antipattern to be testing multiple things at once in a single test.

[Zearin]

It is unclear to me whether there's a benefit to this for hTest (which doesn't mean one doesn't exist, it could also mean I'm missing something).

Okay.

Other testing libraries bunch up all their tests in a single callback, so they need the stack trace to figure out what test failed. hTest doesn't have this issue […]

I don’t know enough about testing framework architecture to compare the pros or cons of either approach. My understanding was that assessing pass/fail—regardless of whether the assessment is a boolean or an AssertionError—can be evaluated any way a test framework desires.

I think a better phrasing for my question would be something more like:

Do you think it would be beneficial to make hTest use AssertionError internally, so there is no need for branching logic when assessing a test’s pass/fail status?

(Apologies if I am being clumsy with any terminology! 🫤 )

[…], and it's a bit of an antipattern to be testing multiple things at once in a single test.

Well, yes…

But consider this snippet from the WPT for DOMRect (mentioned in #116):

var r = new DOMRect()

r.x = 5
assert_equals(r.x, 5, 'Expected value for x is 5')
assert_equals(r.left, 5, 'Expected value for left is 5')
assert_equals(r.right, 5, 'Expected value for right is 5')

Even though there are 3 assertions, this snippet makes sense to my brain as a “single” test. These are the consequences that should happen when you mutate the x of a DOMRect.

Do you think that qualifies as an antipattern?

(I’m not trying to be a smart-ass asking that question! I want to learn if my assessment of that snippet needs refinement. ☻)