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

test.each should perform string interpolation with object properties #10394

Closed
nth-commit opened this issue Aug 11, 2020 · 5 comments · Fixed by #11388
Closed

test.each should perform string interpolation with object properties #10394

nth-commit opened this issue Aug 11, 2020 · 5 comments · Fixed by #11388

Comments

@nth-commit
Copy link

🚀 Feature Proposal

When giving an array of objects to the test.each overload that accepts an array, and not a template strings table, jest should interpolate the object's properties into the test name.

Motivation

The current interpolation of template strings works great, but it doesn't provide any hook for type-safety. This is problematic when scaling up to large and complex test cases, and in TypeScript, it allows any to sneak into your test functions. It also is more intuitive, it left me wondering for a while why a transformation to a type-safe version of a test wasn't causing interpolation of the test case.

Example

We can do something like this right now:

test.each`
  a    | b    | expectedResult
  ${1} | ${1} | ${2}
  ${2} | ${2} | ${4}
`('add($a, $b) === $expectedResult', ({ a, b, expectedResult }) => {
  expect(a + b).toEqual(expectedResult);
});

Which will output the test cases:
√ add(1, 1) === 2
√ add(2, 2) === 4

In order to achieve type-safety on the same test, I would make this transformation:

type AddExample = {
  a: number;
  b: number;
  expectedResult: number;
};

test.each<AddExample>([
  { a: 1, b: 1, expectedResult: 2 },
  { a: 2, b: 2, expectedResult: 4 },
])('add($a, $b) === $expectedResult', ({ a, b, expectedResult }) => {
  expect(a + b).toEqual(expectedResult);
});

Which I would expect should output the same test cases as above, but instead:
√ add($a, $b) === $expectedResult
√ add($a, $b) === $expectedResult

Pitch

It is isomorphic to functionality in the core library, but I believe it cannot be implemented as an extension.

@SimenB
Copy link
Member

SimenB commented Aug 12, 2020

@mattphillips thoughts? Seems reasonable to me

@mattphillips
Copy link
Contributor

This has been something I've wanted to add for a while but not got around to it and I think we should add parity with the tagged template table with $ syntax for sure 👍

@nth-commit
Copy link
Author

Hey @mattphillips, I was looking at the code to see how I could contribute this change. Was wondering what your thoughts were on ensuring it's not breaking. Perhaps if the test name contains any of the printf special characters, use the printf formatting logic, else use variable interpolation?

@jeysal
Copy link
Contributor

jeysal commented Oct 25, 2020

Found this in my inbox and noticed it hasn't been replied to, so I'll just go ahead and answer from my perspective 😅
@nth-commit I would say as long as we land it in a major version (27.0.0 is likely coming up soon), it'd be fine to have the small breaking change. It's particularly small since only existing $variables will be interpolated, $b if there is no b variable in the template string is already being ignored, so most test case names even if they have $ in their name will not be affected.

@github-actions
Copy link

github-actions bot commented Jun 8, 2021

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants