Human-readable context for expectations

[timoxley]

If there's multiple expectations in a single it , currently it appears to be impossible to figure out which expectation actually failed without cross-referencing the failure with line numbers in your code.

test('api works', () => {
    expect(api()).toEqual([]) // api without magic provides no items
    expect(api(0)).toEqual([]) // api with zero magic also provides no items
    expect(api(true)).toEqual([1,2,3]) // api with magic enabled provides all items
})

Which expectation failed? The first or the second?

It would be nice if there were some human readable context that made it immediately clear which expectation failed and what the expectation output actually means in human terms, without having to find the line number at the top of the stack trace and mapping that back to the code.

---

Compare the tape equivalent below. Ignore that tape doesn't bail after the first assertion failure.tape prints out a human-readable message above each expectation failure, allowing you to know exactly which test failed without going back to the test file.

Note this also pushes the human-readable noise off to the end of line in the test source, where you might write a comment anyway.

test('api works', t => {
  t.deepEquals(api(), [], 'api without magic provides no items')
  t.deepEquals(api(0), [], 'api with zero magic also provides no items')
  t.deepEquals(api(true), [1,2,3], 'api with magic enabled provides all items')
})

---

It seems the only way to attach human-readable information to errors with jest is to wrap everything in an additional it which is unnecessarily verbose IMO.

describe('api works', () => {
  test('api without magic provides no items', () => {
    expect(api()).toEqual([])
  })
  test('api with zero magic also provides no items', () => {
    expect(api(0)).toEqual([])
  })
  test('api with magic enabled provides all items', () => {
    expect(api(true)).toEqual([1,2,3])
  })
})

---

Ideally, one could attach some human-readable context onto the end of the expect somehow.

e.g.

Context message as additional optional parameter for assertion methods:

test('api works', () => {
    expect(api()).toEqual([], 'api without magic provides no items')
    expect(api(0)).toEqual([], 'api with zero magic provides no items')
    expect(api(true)).toEqual([1,2,3], 'api with magic enabled provides all items')
})

Or context message as a chained .because or .why or .comment or .t or something:

test('api works', () => {
    expect(api()).toEqual([]).because('api without magic provides no items')
    expect(api(0)).toEqual([]).because('api with zero magic provides no items')
    expect(api(true)).toEqual([1,2,3]).because('api with magic enabled provides all items')
})

Alternatively, it'd be even better perhaps if jest could simply read the file and print the actual source code line that expectation itself is on.

[cpojer]

Hey! So we actually used to have this in Jasmine but found that over thousands of test files at FB, nobody used it. So for now we are printing a nice error message with approximate information and a stack trace that will lead to the expectation (just like in your screenshot). I agree we could print the line that throws but quite often the assertion is multiple lines long:

expect(a).toEqual({
  …
});

so this wouldn't actually look so good and we'd have to use a parser to parse the JS and extract the relevant info (and collapse long lines) or something similar to make it pretty.

Personally I think we are showing enough information for now but happy to reconsider. If you have ideas for something that isn't very complex but adds more context which helps resolve issues faster, let me know.

[timoxley]

we actually used to have this in Jasmine but found that over thousands of test files at FB, nobody used it

@cpojer so the pattern is to wrap each assertion in an it? and/or just trust in the line numbers?

Is it possible that this pattern has been adopted less because it's better or worse, but more just for consistency with the existing tests? or perhaps not knowing the feature exists? I didn't know this was in Jasmine.

I agree we could print the line that throws but quite often the assertion is multiple lines long

Refactoring to a single line could encourage more semantic information in the assertion? Perhaps?

const adminUser = {
  …
}
expect(a).toEqual(adminUser);

Personally I think we are showing enough information for now but happy to reconsider

The example above shows that it's difficult to discover exactly which assertion failed unless you add verbose (IMO) wrappers around everything. This is especially true in a transpiled environment where sourcemap line numbers aren't always accurate. I believe that quickly and accurately understanding broke and where is important, as are concise tests.

If you have ideas for something that isn't very complex but adds more context which helps resolve issues faster, let me know.

I made a few suggestions above:

• additional optional parameter for assertion methods
• chained context message

Are you looking for something simpler, or different?

[aaronabramov]

hey @timoxley! we already thought about adding something like this.

so the issue with the first option is that some matchers have optional arguments, and that makes things more complicated.

e.g. here on the second case we won't know if the argument is a proximity or an error message

expect(555).toBeCloseTo(111, 2, 'reason why');
expect(555).toBeCloseTo(111, 'reason why');

second suggestion won't work because the matcher will throw as soon as something does'n meet expectation

expect(1).toBe(2)/* will throw here */.because('reason');

we could attach the reason before the matcher executes, like this:

expect(1).because('reason').toBe(2);
// or 
because('reason').expect(1).toBe(2);

but this API doesn't really look that good.

another option would be to add a second arg to expect

expect(1, 'just because').toBe(2);

but it is pretty much the same as the previous option.

[cpojer]

The reason why I think this isn't very useful is because engineers don't want to waste time writing tests. Anything we do to make it harder for them will just lead to worse tests.

In the past, the best solution was actually to create custom matchers. We'll introduce expect.extend in the next version of Jest and it will allow you to easily create matchers like:

expect(a).toEqualMySpecificThing(…)

which should allow you to write more expressive failure messages. I've seen this used a lot in projects like Relay. See all the matchers: https://github.com/facebook/relay/blob/master/src/tools/__mocks__/RelayTestUtils.js#L281

[cpojer]

Closing due to inactivity but happy to reopen if there are good ideas.

[timoxley]

@cpojer @DmitriiAbramov apologies for delay.

A second arg to expect or chaining a reason with .because would be great. What needs to be done to make this happen or not?

[timoxley]

engineers don't want to waste time writing tests

@cpojer Agreed! In addition to not wanting to waste time debugging tests, this is exactly why I believe a less verbose API with more failure context would be preferable.

For some concrete numbers, using the simple example from my comment above, to get equivalent assertions + context with tape, Jest requires the programmer write nearly double the amount of ceremonial boilerplate:

• 1.8x the lines (6 vs 11)
• 2x the indentation (1 vs 2)
• 2x the parens/curlies (24 vs 48) !

This could be improved!

// tape
test('api works', t => {
  t.deepEquals(api(), [], 'api without magic provides no items')
  t.deepEquals(api(0), [], 'api with zero magic also provides no items')
  t.deepEquals(api(true), [1,2,3], 'api with magic enabled provides all items')
  t.end()
})

// jest
describe('api works', () => {
  test('api without magic provides no items', () => {
    expect(api()).toEqual([])
  })
  test('api with zero magic also provides no items', () => {
    expect(api(0)).toEqual([])
  })
  test('api with magic enabled provides all items', () => {
    expect(api(true)).toEqual([1,2,3])
  })
})

---

Update: I suppose you could write the jest tests on a single line with arrows:

// jest
describe('api works', () => {
  test('api without magic provides no items', () => expect(api()).toEqual([]))
  test('api with zero magic also provides no items', () => expect(api(0)).toEqual([]))
  test('api with magic enabled provides all items', () => expect(api(true)).toEqual([1,2,3]))
})

This makes for some longer lines, but does improve the stats we compared earlier somewhat:

• 0.8x the lines (6 vs 5)
• 1x the indentation (1 vs 1)
• 1.75x the parens/curlies (24 vs 42)

However I think having the test description at the start of the line, without a linebreak, makes it harder to visually parse the logic because it puts the "meat" of the test, i.e. the actual assertions, at some arbitrary column position.

Parsing the code is more important than reading the test description, which is basically just a glorified comment. This is why nobody writes comments at the start of the line .e.g. this would be sadomasochistic madness:

/* api without magic provides no items */ expect(api()).toEqual([])
/* api with zero magic also provides no items */ expect(api(0)).toEqual([])
/* api with magic enabled provides all items */ expect(api(true)).toEqual([1,2,3])

Ideally all the assertion code would line up neatly in the same column so it's easily parsed by a human. Based on this thinking, I'd strongly opt for the trailing .because form rather than alternative suggestion of a second argument to expect.

[cpojer]

Thanks for keeping the conversation going. Note, that you also don't need the describe block, further making things smaller. .because won't work unfortunately because when the matcher throws (which happens before .because is called), we won't have a way to extract the name.

[timoxley]

Use the last arg of each matcher function then?

[aaronabramov]

It would only work if we add it as a second arg of expect.
We can't add it as a the last arg for every matcher function because of ambiguity
e.g.

expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

[jayphelps]

Closing due to inactivity but happy to reopen if there are good ideas.

@cpojer it's unclear if the jasmine (and others) way of expect(value).toBe(something, 'because message') has been ruled out?

One example is testing redux-saga/redux-observable stuff where you're testing a state machine. It's very helpful to have a descriptive message about at what state did it fail. That example is contrived so the descriptions are as well, though..

[aaronabramov]

@jayphelps we're not using the jasmine way any more since we rewrote all jasmine matchers

[jayphelps]

@DmitriiAbramov sorry my question wasn't clear. Has the jasmine way of doing it been ruled it to be added back? Doing the same thing they allow.

[aaronabramov]

@jayphelps as i said before, it won't work for all matchers because of the ambiguity.

expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

and sing jest matchers can be extended with a third party packages i don't think it's a good idea to mess with the argument list

[aaronabramov]

the cleanest option is probably to have it as a second argument of expect, since it always takes exactly one argument.

expect(123, 'jest because').toEqual(123);

i'm not sure if we want to overload the API though. We almost never used it in facebook test suites, and for special cases i think it'm easier to just define a new test:

beforeEach(someSharedSetup);
test('reason or description', () => expect(1).toBe(1));

it's just a few lines more :)

[thymikee]

Or you can even put it into another describe() call.

[jayphelps]

@DmitriiAbramov The annoying cases are when you build up state, like in a state machine for sagas, epics, etc. Each test requires the previous state changes, isolating them requires a ton of duplication without any gain AFAIK.

it('stuff', () => {
  const generator = incrementAsync();

  expect(generator.next().value).toBe(
    call(delay, 1000)
  );

  expect(generator.next().value).toBe(
    put({ type: 'INCREMENT' })
  );

  expect(generator.next()).toBe(
    { done: true, value: undefined }
  );
});

---

Or you can even put it into another describe() call.

Can you elaborate this? Nesting describe calls AFAIK was just for dividing section titles, tests are still run concurrently right?

[thymikee]

Test suites (files) run concurrently, test() calls don't.

[aaronabramov]

i'm starting to think that something like

test('111' () => {
  jest.debug('write something only if it fails');
  expect(1).toBe(2);
});

can be a thing

[franciscop]

From this discussion and this repository I think a nice and semantic one would be:

it('has all the methods', () => {
  since('cookie is a method').expect(reply.cookie).toBeDefined();
  since('download is a method').expect(reply.download).toBeDefined();
  since('end is a method').expect(reply.end).toBeDefined();
  // ...
});

The usage is similar to the because one, but it just makes more of sense semantically.

If you like this I might be able to work out a PR adding the since functionality.

[nylen]

Please implement an easy way to do this. I don't use it very often, but especially for more complicated tests, it's helpful to know exactly what is failing without having to go digging.

Please don't say "rewrite your test suites to be simpler". The only thing engineers hate more than writing test suites is rewriting test suites.

Another proposal that I've seen somewhere, I forget where It was in this very same issue, with an explanation of why it wouldn't work. I should probably get some sleep :)

[franciscop]

I got some simple "prototype" demo working, I would need to implement the recursion now. It is a thin wrapper using Proxies around the global variables and then over each method. However, Proxies are not supported by older browsers and cannot be polyfilled so it might not be acceptable for Jest. This is the general structure for the wrapper:

const since = (text) => {
  return new Proxy(global, {
    get: (orig, key) => {
      return (...args) => {
        try {
          const stack = orig[key](...args);
          return new Proxy(stack, {
            get: (orig, key) => {
              return (...args) => {
                try {
                  const ret = orig[key](...args);

                  // ... implement recursion here

                } catch (err) {
                  console.log('2', key, text, err);
                  throw err;
                }
              }
            }
          });
        } catch (err) {
          console.log('1', key, text, err);
          throw err;
        }
      };
    }
  });
};

There are three realistic options:

• This way is acceptable so it should be added to the main Jest library. I clean it up and create a PR.
• Dig deeper into Jest and modify the core library. A lot of work, so wouldn't do anything until some member(s) say something semi-oficially on this issue/direction.
• Finish it this way and publish it as a package. Undesirable since it's not easily discoverable.

Edit: see it in action:

describe('Test', () => {
  it('works', () => {
    since('It fails!').expect('a').toEqual('b');
  });
});

[KazimirPodolski]

You need expectation context to make test results sane when you have non-trivial tests. Real-world tests wouldn't always be that simple.

Remember custom matchers - they hide mathing complexity. But when test fails, hiding this complexity is not what you want becase you want maximum info about failure. Expectation context alows you to provide this context manually. Not ideal I guess, some kind of automatic context would be better, but it is the only way I've seen by now.

When I broke something and it fails, with Jest I have to debug it manually or add logging or whatever modifications. Which is much less convenient than just look at test run results.
In Jasmine for example, we have an ability to print some context to make more sense about failure.
In Java's most popular test framework JUnit we have exact same feature too.

Sorry if I'm mistaken, but I don't see any technological counter-arguments to this feature here. And things like "this shouldn't be added because it won't look good" are just ridiculous.

[gaearon]

Can we reopen? Even jest.debug() as suggested by @aaronabramov above would be helpful to me.

[ZacharyRSmith]

This:

it('has all the methods', () => {
	since('cookie is a method', () => expect(reply.cookie).toBeDefined());
});

can be supported by adding this:


// setupTestFrameworkScriptFile.js
// http://facebook.github.io/jest/docs/configuration.html#setuptestframeworkscriptfile-string
global.since = (explanation, fn) => {
	try {
		fn();
	} catch(e) {
		e.message = explanation + '\n' + e.message;
		throw e;
	}
};

[ZacharyRSmith]

Also, jasmine-custom-message looks similar to what's requested:

describe('test', function() {
  it('should be ok', function() {
    since(function() {
      return {'tiger': 'kitty'};
    }).
    expect(3).toEqual(4); // => '{"tiger":"kitty"}'
  });
});

[tarjei]

I think another modifier quickly becomes unreadable. T 2018-04-19 13:47 GMT+02:00 λ • Geovani de Souza <[email protected]>:

…

What about chaining another modifier? expect(foo).toEqual(bar).because('reason with %s placeholders') Or maybe a function expect(foo).toEqual(bar).explainedBy((result) => `Lorem ipsum ${result}`) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1965 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAM5PwBCvET1KdEDeDEF7gGo708Naj8oks5tqHlSgaJpZM4Kc6Uu> .

--

__________________ Tarjei Huse Mobil: 920 63 413

[SimenB]

The way expect work is by throwing, so that wouldn't work anyways.

I think either expect(something, 'some helpful text on failure').toEqual(somethingElse) or expect.context(something, 'some helpful text on).toEqual(somethingElse) are the best alternatives, but I don't really like either of them

[callumlocke]

Can this be reopened? It seems Jest still has no good solution for testing how state changes over multiple interactions, for example:

• testing how a stateful React container changes in response to a series of events
• testing how a web page changes throughout multiple interactions using Puppeteer

Both of these cases require performing a series of actions, and asserting how the state changed (or didn't change) after each action, so multi-assertion tests are sometimes necessary. It's not always possible to solve this kind of problem with beforeEach.

[kentcdodds]

I keep finding situations where this would be really useful. Specifically when I'm running multiple interactions and assertions as @callumlocke explains.

If we come up with an API that folks don't hate, is this something you'd be willing to pursue? I really think this would be a valuable and much used feature.

[rickhanlonii]

Here's a summary of the proposed solutions:

expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

expect(api(), 'api without magic provides no items').toEqual([])
expect(api()).because('api without magic provides no items').toEqual([])
since('api without magic provides no items').expect(api()).toEqual([]))
because('api without magic provides no items').expect(api()).toEqual([]))
jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

Note that a trailing .because() is not possible, so not included as an option. Same for a trailing arg in each matcher.

All four options in the first group are supported today. Personally, I find that the first option (a code frame with a comment) works great. And even better than that is using a custom matcher (option 4).

I think what's we need to understand to make movement on this is: what's more appealing about the options in the second group than the options in the first? What does the second group add which can justify core maintenance for all of the matchers we provide (across async matchers, asymmetric matchers, spy matchers, throw matchers, promise matchers, and custom matchers)?

[eric-burel]

Hi,
You basically got a few use cases:

• Multiple assertions tests (you need to assert multiple things in a test)
• Dynamically generated assertion context (you want a variable in your failure message to make it clearer, e.g for printing a specific field of your failing object because you got a lot of tests)
• Dynamically generated assertions (you make a loop that generate assertions)

First group options are mainly meant for the first use case. If you encounter the need for dynamically generated assertion, as proposed, you can nest calls to it and test, so that a test can generate new tests in a loop. The problem is that you generate tests and not assertions. Imagine that I want to assert something on each element of a 1000 elements array, this will bloat the test summaries.

Since those dynamic use cases are still rare though, imo we should stick for the solution that requires minimal work for the maintainers. I personally like the because/since solution, because it sounds quite simple. I guess the implementation would be mostly wrapping expect in a try/catch that prints the message and returning it?
jest.debug sounds weird, to me debugging is printing a message even if the tests actually passes
The "last argument" option is also good but I am not sure if it is doable since expect can accept a variable number of arguments?

[kentcdodds]

I'm fine with any option. I just want the feature. I'm not huge on the jest.debug API either, but if it's the only one that makes sense I'm fine with it because I just want this feature.

[rickhanlonii]

@kentcdodds what about the four existing options?

@eric-burel have you seen test.each and describe.each added in Jest 23 (available as a standalone for Jest <23)?

[kentcdodds]

Like I said, I don't really care which option we go with. I just want the feature to exist. I guess if I were to sort them by order of preference it would be:

1. expect(api(), 'api without magic provides no items').toEqual([])
2. because('api without magic provides no items').expect(api()).toEqual([]))
3. since('api without magic provides no items').expect(api()).toEqual([]))
4. expect(api()).because('api without magic provides no items').toEqual([])
5. jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

(test|describe).each is great, but doesn't solve the issue where you want to have multiple actions/assertions in a single test.

[rickhanlonii]

The feature does exist today with four options:

expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

What is wrong with these? The proposed new solutions only seem to be marginally better than these existing solutions. What benefits do they bring over what we have that justify the maintenance cost?

[eric-burel]

@rickhanlonii Nice I did not know about test.each, that's truly a great feature, thanks for pointing this out. I think it solves the issue for my 3rd use case, dynamically generated test from an array.

So it left the second I listed: having a dynamically generate failure message, which would make debugging faster. I don't have much use cases right now, maybe when you test an object field value, you would like to print the whole object on failure. That's legitimate imo, as anything that makes writing test easier, even if marginal or a bit redundant. After all we can both write it and test, unless there is a difference I don't know about this is mostly for comfort.
It is marginal but really something expected (no pun) by users, as this thread shows.

Edit: creating a test in another test with it or test and a dynamically generated name for the test is a valid solution but I really don't like creating a test when I mean creating an assertion. I would never have guessed it was possible if the solution hasn't been given in this thread.

[cognivator]

This is crazy. Just add a second, optional parameter to expect(). Those of us who want to use it will (selectively), and those who don't, won't.

Mocha has been doing this forever... it's one of the reasons I abandoned Jasmine years ago (the other being much better timer mocking.) If I weren't having to join the React bandwagon, I wouldn't be using Jest or any other Jasmine derivative.

[johnpmitsch]

Printing out a message on error is a convention in so many other testing frameworks and I was surprised to not see it in Jest. I've found a lot of helpful examples in this thread (thank you for those), but adding an explicit way to print a custom error on test failure would be a nice addition to Jest's usability. This would make it easier for developers who are used to other testing frameworks (including non-JS ones) to ramp up on Jest.

[SimenB]

@mattphillips do you think it's possible to do something similar to jest-chain here to allow a solution to exist in userland? E.g. second argument to expect

[talbronfer]

Honestly, this is something very standard in most JS testing frameworks. Very disappointed not to find it in Jest as we write all of our tests with a custom error message.

[mattphillips]

@SimenB sorry I only noticed your message this morning!

Yes this is doable in userland, I've just knocked it up and released it as jest-expect-message https://github.com/mattphillips/jest-expect-message

Feedback welcome 😄

[SimenB]

Awesome, thanks for doing it!

[Atomox]

@cpojer

The reason why I think this isn't very useful is because engineers don't want to waste time writing tests. Anything we do to make it harder for them will just lead to worse tests.

Two things:

1. Adding an optional second argument to expect() is hardly making anything harder for developers.
2. The last thing developers want to do is waste time debugging what caused the test to fail. Often expects vs received is a good way to check if a condition was met, but often not enough context as to what caused it to fail.

I used Mocha/Chai, as well as tape, before coming to Jest, and this is really a deal breaker. What do we have to do to get a custom message support into expect?

Telling us to expect.extend in order to create a custom matcher sounds exactly like what you were trying to avoid in your first argument: "engineers don't want to waste time writing tests."

[cwellsx]

I find it easy to open the unit test and look at the line number, so the use-case in the OP doesn't bother me.

The use case that bothers me is when I have a loop inside a test, e.g. to test every value of an enum, for example like this:

it("Should contain at least one word of every wordType", () => {
  for (const wordType of wordTypes) {
    expect(words.find((word) => word.wordType === wordType)).toBeTruthy();
  }
});

If that fails then I don't know which wordType value failed.

My work-around was to replace that with a message which contains the test result, and expect that the message contains the expected test result (i.e. true). If it fails then Jest prints the message which contains the additional information.

    expect(`${wordType} ${!!words.find((word) => word.wordType === wordType)}`).toEqual(`${wordType} ${true}`);

Jest prints this ...

expect(received).toEqual(expected)

Difference:

- Expected
+ Received

- 6 true
+ 6 false

... which tells me that the wordType was 6 when it failed.

Or more readably something like ...

    if (!words.find((word) => word.wordType === wordType)) {
      expect(`Didn't find a word with wordType '${wordType}'`).toEqual(null);
    }

[mattphillips]

@cwellsx check out parameterised tests with test.each this way each wordType will be an independent test with a descriptive title (based on the value)

[DaanVandenBosch]

This would be incredibly useful in tests like this:

test("compare ArrayBufferCursors", () => {
    const orig: ArrayBufferCursor;
    const test: ArrayBufferCursor;

    expect(test.size).toBe(orig.size);

    while (orig.bytes_left) {
        expect(test.u8()).toBe(orig.u8());
    }
});

Right now I only know some byte in the ArrayBufferCursor is wrong but I have no idea which one. Being able to add an index as context would make debugging much easier. Thankfully some people have presented workarounds here but they're all ugly and slow.

[prantlf]

@rickhanlonii, I understand that you want to reduce the maintenance costs of jest, but options that you offer in your comment increase the maintenance of unit tests of all other projects. If I want to explain an assertion using toEqual, which is otherwise perfectly enough, are you really suggesting me introducing a custom matcher?!

While there are cases with repetitive tests, where it.each are useful, having to add an unnecessary code for a simple comment on an assertion makes this test framework heavier to use.

This discussion and emerging of jest-expect-message reminds me about the beforeAll issue in Jasmine...

[sevans415]

I may be misunderstanding the OP's request here but the problem that I was trying to solve and brought me to this issue thread was solved just using a simple try / catch and wrapper around jest.expect. All I wanted to do was log the entirety of the objects that I expected vs the ones that I received + some basic logs explaining the significance. Of course, this could be extended to do just about whatever you want.

The most generic version of this might look like:

in some test utility file...

const myExpect = (expectFn, errorCallback) => {
  try {
    expectFn();
  } catch (err) {
    errorCallback();
    throw new Error(err);
  }
};

// in the actual test suite...

const context = { hello: "world", results, expected };
myExpect(
    () => expect(results).toEqual(expected),
    () => console.error("[Error] -- context:", JSON.stringify(context))
);

[jakub-bao]

+1
Hi, I'd really love this feature as well. It would make my life so much easier.

[hiddenist]

I found this closed issue while trying to find out what was the syntax for exactly this in jest. I'm surprised that it's not present, already.

I would also like to see this added.

[timoxley]

Closing due to inactivity but happy to reopen if there are good ideas.

@cpojer can we reopen this? There have been some good ideas.

[github-actions]

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.