You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The message property in t.throws is really ergonomic - it can be a string, RegExp, or even a function. t.like should be just as ergonomic with strings:
constoutput=foo();t.like(output,{name: 'foo',source: /foo comes from/,});
A motivating example is trying to convert this test from npm-user to use t.like:
Currently like is a partial deepEqual, selecting from the actual (first argument) just those properties that exist in the expected (second argument). How would we do that if expected contains a regular expression value?
I agree that this looks useful, and your logic makes sense, but I don't immediately see how this could be implemented. Don't let that stop you though 😉
It may also technically be a breaking change, in that if you've written an existing assertion expecting a regular expression, and your actual value changes to a string, that happens to match… the test passes when it shouldn't. OK that seems unlikely.
The
message
property int.throws
is really ergonomic - it can be astring
,RegExp
, or even a function.t.like
should be just as ergonomic with strings:A motivating example is trying to convert this test from
npm-user
to uset.like
:The text was updated successfully, but these errors were encountered: