Skip to content
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

Allow regexes in t.like #3309

Open
tommy-mitchell opened this issue Feb 26, 2024 · 4 comments
Open

Allow regexes in t.like #3309

tommy-mitchell opened this issue Feb 26, 2024 · 4 comments
Labels

Comments

@tommy-mitchell
Copy link
Contributor

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:

const output = 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:

const user = await npmUser('sindresorhus');

t.like(user, {
	name: 'Sindre Sorhus',
	avatar: /npm-avatar/,
	email: '[email protected]',
});
@novemberborn
Copy link
Member

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?

@Saberian1992

This comment was marked as duplicate.

@tommy-mitchell
Copy link
Contributor Author

Maybe:

  • If expected.prop is a RegExp and actual.prop is a string:

    1. Check if actual.prop matches expected.prop

    2. If false, fail the test. The current descriptors (string vs regex) can stay as-is:

    - str: 'string',
    + str: /string/,
  • If expected.prop is a RegExp and actual.prop is a RegExp:

    1. No change. Only pass if the two regexes are the same.
  • If expected.prop is a string and actual.prop is a RegExp:

    1. No change. The test should still fail.

@novemberborn
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants